• Рассуждение на тему, какую базу данных выбирать

      Эта статья для вас, если вы:


      • выбираете базу данных для нового проекта и изучаете информацию про разные варианты;
      • считаете, что текущая база данных не устраивает вас по каким то параметрам и вы хотите ее сменить, но у вас нет хорошего специалиста;
      • просто хотите почитать в одной статье про несколько баз данных и когда можно их использовать.

      Моя статья не для вас, если вы:


      • хорошо умеете готовить свою любимую БД, оптимизировать индексы, настраивать и всякое такое;
      • имеете в штате хорошего специалист, который сможет аргументировано выбрать нужный вашему проекту вариант. специалист должен быть действительно хорошим, а не «экспертом на диване»;
      • обслуживаете проект с так называемым «big data», то есть у вас огромные базы, десятки или сотни серверов в кластере и всякое такое — ну у вас как бы должен быть в штате один или несколько специалистов.

      О чем пойдет речь в статье?


      Я разберу в своей статьи некоторые типичные и не очень варианты выбора баз данных, а если быть более точным — подходы к выбору. Когда следует остановится на том, что используют большинство, а когда можно и задуматься над новым и неизведанным. Я опишу СУБД MySQL, PostgreSQL, MongoDB, Redis, CouchDB/PouchDB и упомяну о Aerospike с Tarantool, парочку других — но в некоторых моментах конкретный выбор не настолько принципиален. Надо понимать, что лучше изначально правильно спроектировать структуру данных, чем выбрать СУБД, а потом уже пытаться придумывать, что в ней собственно хранить.
      Итак, начнем.
      Читать дальше →
    • Продвинутая работа с JSON в MySQL

      • Перевод

      У MySQL нет возможности напрямую индексировать документы JSON, но есть альтернатива: генерируемые столбцы.


      С момента введения поддержки типа данных JSON в MySQL 5.7.8 не хватает одной вещи: способности индексировать значения JSON. Для того, чтобы обойти это ограничение, можно использовать генерируемые столбцы. Эта возможность, представленная в MySQL 5.7.5, позволяет разработчикам создавать столбцы, содержащие информацию, полученную из других столбцов, предопределенных выражений или вычислений. Генерируя столбец из значений JSON, а затем индексируя его, можно практически индексировать поле с JSON.

      Читать дальше →
      • +28
      • 8,5k
      • 9
    • Функциональность отношений

        В классических реляционных базах данных бинарная связь кортежей основана на использовании ключей: первичных и внешних. При этом, интерпретация этой связи осуществляется за пределами логической структуры базы данных, где она (интерпретация) может иметь достаточно произвольный характер. Естественно, в рамках ограничений, предписанных реляционной моделью.

        В объектной же парадигме для реализации связи объектов используют их идентификаторы. Причем, если связи объектов придать строгую симметричную форму: в виде пары прямая | обратная ссылка, то это позволяет практически полностью заменить Select естественной навигацией по ссылкам. Но что не менее важно, симметричная форма делает связь объектов полноправным и самостоятельным элементом логической структуры базы данных, обладающим собственным поведением и функциональной зависимостью от других действующих связей.

        Настоящая статья посвящена рассмотрению самых различных поведенческих аспектов связи объектов, реализация которых позволяет интегрировать значительную часть бизнес-логики приложения непосредственно в логическую структуру базы данных, тем самым избавляя разработчика от рутины кодирования.
        Читать дальше →
      • «Ура, нас зафичерили!» или Как сменить дата-центр под нагрузкой и без даунтаймов, когда всё летит к чертям



          Пару лет назад мы располагались в самом cost-effective (читай: «дешевом») дата-центре в Германии. Чтобы вы понимали условия — роутинг мог сбоить от стойки к стойке или внутри неё; свитч в стойке перегружался или зависал; сам дата-центр постоянно ддосили; жесткие диски выходили из строя; материнские платы и сетевые карты сгорали; сервера произвольно выключались, перезагружались, а сетевые кабели выпадали как осенние листья во время урагана.

          Периодически, когда приходило время скейлиться горизонтально, в ДЦ еще и место заканчивалось, и нам предлагали другую локацию, в другом городе, что для наших условий (ограничения схемы данных, топология кластера и критичность времени ожидания клиента) было неприемлемо.

          Наступила точка кипения и мы решили переезжать. Хотя в какой-то момент даже казалось, что дешевле нанять больше обслуживающего персонала, чтобы менеджерить ситуации в вышеупомянутом ДЦ. Но в итоге, чтобы «стало более лучше жить» — мы выбрали стабильность.
          Выбор остановился на дата-центре в Голландии, в Амстердаме. А вот тут самое интересное: к тому времени у игры уже был приличный DAU, переезд нужно было осуществить онлайн, без даунтаймов, одновременно на обе платформы (Android и iOS). Мало того, мы получили фичеринг на Google Play, маркетинг еще и запустил рекламную кампанию. Как понимаете, дополнительного трафика стало очень и очень много.

          В общем, задачка не самая обыденная и вот как мы с ней справлялись.
          Читать дальше →
        • Структуры данных со свойствами программы

            Как известно, база данных – это хранилище структурированной информации, пассивное по своей сути. Бизнес-логика приложения реализуется где-то вне базы, в виде «набора действий для достижения требуемого результата». В случае внесения изменений в хранимый набор данных результатом должно стать новое состояние базы. В краткой форме это можно записать как-то так: событие → {действия} → результат. Изменим эту формулировку на: событие → правила → результат, и посмотрим, что из этого получится.
            Читать дальше →
          • Как мы выбирали между Elastic и Tarantool, а сделали свою (самую быструю) in-memory БД. С Join и полнотекстовым поиском

              Всем привет.


              С середины 2016 года мы проектируем и разрабатываем новое поколение платформы. Принципиальное отличие от первого поколения — поддержка API "тонкого" клиента. Если старая платформа предполагает, что на клиента при запуске загружается метаинформация о всем контенте, который доступен для абонента, то новая платформа должна отдавать срезы данных отфильтрованные и отсортированы для отображения на каждом экране/странице.


              Высокоуровневая архитектура на уровне хранения данных внутри системы — постоянное хранение всех данных в централизованном реляционном SQL хранилище. Выбор пал на Postgres, тут никаких откровений. В качестве основного языка для разработки — выбрал golang.


              У системы порядка 10м пользователей. Мы посчитали, что с учетом профиля теле-смотрения, 10М пользователей может дать сотни тысяч RPS на всю систему.



              Это означает, что запросы от клиентов и близко не стоит подпускать к реляционной SQL БД без кэширования, а между SQL БД и клиентами должен быть хороший кэш.


              Посмотрели на существующие решения — погоняли прототипы. Данных, по современным меркам у нас немного, но параметры фильтрации (читай бизнес-логика) — сложные, и главное персонализированные — зависящие от сессии пользователя, т.е. использовать параметры запроса как ключ кэширования в K-V кэше будет очень накладно, тем более пейджинг и богатый набор сортировок никто не отменял. По сути, под каждый запрос от пользователя формируется полностью уникальный набор отфильтрованных записей.

              Читать дальше →
            • Ммм, длинные выходные!
              Самое время просмотреть заказы на Фрилансим.
              Мне повезёт!
              Реклама
            • KDB

                кдвп


                Привет, Хабр !


                В статье я опишу идею хранения в достаточно известной колоночной базе данных KDB, а так же примеры того, как к этим данным обращаться. База существует еще с 2001 года, и на данный момент занимает высокие места на сайтах со сравнением подобных систем (см., например, тут)

                Читать дальше →
              • Akumuli — база данных временных рядов

                Привет! В этой статье я хочу рассказать о проекте Akumuli, специализированной базе данных для сбора и хранения временных рядов. Я работаю над проектом уже больше четырех лет и достиг высокой стабильности, надежности, и возможно изобрел кое-что новое в этой области.


                Временной ряд это упорядоченная во времени последовательность измерений, если говорить максимально просто, это то что можно нарисовать на графике. Временные ряды естественным образом возникают во многих приложениях, начиная с финансов и заканчивая анализом ДНК. Наиболее широкое применение базы данных временных рядов находят в мониторинге инфраструктуры. Там же часто наблюдаются самые серьезные нагрузки.


                Time-series in finance


                “Мне не нужна TSDB, у меня уже есть Х”


                Х может быть чем угодно, начиная с SQL базы данных и заканчивая плоскими файлами. На самом деле все это действительно можно использовать для хранения временных рядов, с одной оговоркой — у вас мало данных. Если вы делаете 10 000 вставок в свою SQL базу данных — все будет хорошо какое-то время, потом таблица вырастет в размерах настолько, что время выполнения операций вставки увеличится.

                Читать дальше →
              • Как сэкономить на спотовых инстансах EC2 с помощью Scylla

                • Перевод
                Спотовые инстансы могут сэкономить вам много денег. Но что если вы работаете с сервисами с сохранением состояния, например, базами данных NoSQL? Основная проблема заключается в том, что в таком случае каждая нода в кластере должна сохранять некоторые параметры — IP, данные и другие конфигурации. В этом посте мы расскажем об опенсорсной NoSQL БД Scylla и о том, как ее можно использовать в спотовых инстансах EС2 для непрерывной работы — с помощью предиктивной технологии SpotInst, а также расширенной функциональности сохранения состояния.


                Читать дальше →
              • PouchDB или что делать когда «интернет стабильный»

                • Tutorial
                В наше время скорость работы WEB-приложения сильно влияет на лояльность пользователей. Зачастую приходится переносить некоторую бизнес-логику в клиентский код, работающий в браузере пользователя.

                В такой ситуации появляется необходимость оперативного получения данных, связанных с задачами. Но иногда время на их запрос с серверной базы данных слишком велико, а порой подключение к сети и вовсе нестабильно или отсутствует. В такой ситуации можно прибегнуть к хранению данных локально у пользователя и синхронизировать по мере необходимости.

                Знакомство


                PouchDB — база данных, которая работает на основе существующих решений по хранению информации в браузере пользователя. По сути, она выступает фасадом и обеспечивает универсальный API независимо от того, в каких условиях запущено приложение.

                image

                Версии браузеров, в которых работает PouchDB:

                • Firefox 29+ (включая Firefox OS и Firefox для Android)
                • Chrome 30+
                • Safari 5+
                • Internet Explorer 10+
                • Opera 21+
                • Android 4.0+
                • iOS 7.1+
                • Windows Phone 8+

                Так как это NoSQL база данных, терминология немного отличается от привычных реляционных решений. Посмотреть разницу можно в таблице соответствия:

                image

                Читать дальше →
              Самое читаемое