• Сравниваем Tarantool с Redis и Memcached

    • Перевод

    image


    Выбираете между Tarantool и Redis или между Tarantool и Memcached? Давайте рассмотрим основные различия, чтобы вам легче было определиться.

    Читать дальше →
  • Применение Tarantool: хранимые процедуры

      image


      Перевод статьи с DZone. Оригинал.


      Я хочу поделиться своим опытом создания приложений для Tarantool, и сегодня мы поговорим об установке этой СУБД, о хранении данных и об обращении к ним, а также о записи хранимых процедур.

      Читать дальше →
    • Фантастик-Elasticsearch. Как мы «укротили» умный поиск по документам

        Полнотекстовый поиск даёт возможность искать документы по текстовому содержимому. Такая необходимость может возникнуть, когда система содержит много текстовых сущностей, а пользователям требуется учитывать эти данные во время поиска. Мы столкнулись с подобной ситуацией при разработке решения для документооборота*. Данные системы хранятся в MS SQL Server или PostgreSQL, а гибкий атрибутивный поиск позволяет находить документы по различной мета-информации. Однако со временем этого стало недостаточно. Перед нами встала задача: научиться искать документы по текстовым свойствам и приложенным файлам.


        Читать дальше →
        • +17
        • 6,5k
        • 9
      • Продвинутая работа с JSON в MySQL

        • Перевод

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


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

        Читать дальше →
        • +28
        • 11,1k
        • 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 базу данных — все будет хорошо какое-то время, потом таблица вырастет в размерах настолько, что время выполнения операций вставки увеличится.

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