• Масштабирование БД в высоконагруженных системах

      На прошлом внутреннем митапе Pyrus мы говорили о современных распределенных хранилищах, а Максим Нальский, CEO и основатель Pyrus, поделился первым впечатлением от FoundationDB. В этой статье рассказываем о технических нюансах, с которыми сталкиваешься при выборе технологии для масштабирования хранения структурированных данных.

      Когда сервис недоступен пользователям какое-то время, это дико неприятно, но всё же не смертельно. А вот потерять данные клиента — абсолютно недопустимо. Поэтому любую технологию для хранения данных мы скрупулезно оцениваем по двум-трем десяткам параметров.
      Читать дальше →
    • Репликация в Tarantool: конфигурирование и использование



        Я вхожу в Tarantool Core Team и участвую в разработке движка базы данных, внутренних коммуникаций компонентов сервера и репликации. И сегодня расскажу, как устроена репликация.
        Читать дальше →
      • Мой адрес не дом и не улица, мой адрес – Советский Союз?

          microBIGDATA или ФИАС в кармане


          Питер Брейгель Младший, Уплата налога, 1640 год

          Прошлый заход на бреющем по объектам зашел. Продолжим разведку боем. Сегодня поговорим о тяжелом. Пусть ещё не о BIG DATA, но работать уже неудобно – достаточно большие объёмы данных. Не каждому влезет в оперативную память целиком, а некоторым не влезет даже на диск (не места мало, а хламу много). Имя нашему подопечному БД ФИАС — база данных федеральной адресной информационной системы. Архив в 5,5 ГБ. И это сжатый в архив XML. После распаковки будут полные 53 ГБ (для распаковки запасайте 110 ГБ). И как начнёшь его парсить да конвертить, то и 110 ГБ будет мало. О потребном размере ОЗУ тоже будет.
          Читать дальше →
        • Боевой полет на Meteor-e

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

            На Хабре уже давно не было статей по Метеору, поэтому хотелось бы поделиться нашей историей.



            Расскажу про наш проект, как мы пришли к Meteor и как на нем летаем. Постараюсь не углубляться в детали или очень специфические вещи — их оставлю на обсуждение, либо отдельную статью.
            Читать дальше →
          • Couchbase в телекоме

            Цифровая трансформация является мировым трендом для крупного бизнеса и жизненно важна для адаптации  предприятия к современным потребностям клиента. Кроме обычной для крупных компаний проблематики централизации систем и объединения биллинговых систем и абонентских БД добавляются требования к высокой доступности и режиму работы в реальном времени к которому клиенты уже привыкли у лидеров индустрии (Google, Amazon, Netflix).


            Новые вызовы требуют новых технологий и подходов, которые необходимы для сокращения времени внедрения удобных клиенту функций, персонализированных коммерческих предложений, быстрой реакции на предложения конкурентов, а так же контроля затрат на системы, ИТ инфраструктуру, датацентры  и квалифицированного персонала. Эти тенденции несут и большой минус: усложнение архитектуры и раздутые транзакционные базы данных, которые не справляются с потоком и обработкой информации. Технологии предыдущего поколения имеют потолок вертикального масштабирования. К примеру, экземпляр СУБД Oracle работает на пределе самого мощного сервера на процессорах x86 при нагрузке в миллиард транзакций в сутки.



            Для того, чтобы выдержать подобную загрузку с которой уже давно сталкивается интернет индустрия используется новый стек технологий, таких как In-Memory кэши и NoSQL базы данных. Так, Apple применяет Cassandra, Сбербанк – Ignite (GridGain), в МегаФон мы применяем Couchbase и Tarantool.


            В МегаФон используются разные архитектурные шаблоны для In-Memory СУБД:


            1. Простой кэш, обновляемый по расписанию или по событию из БД и приложений
            2. Все изменения в БД осуществляются через кэш (write-through сценарий), например, подключение Oracle клиента к DCP Couchbase

            Читать дальше →
          • Нельзя так просто взять и написать SELECT, если вендор не разрешает… но мы таки напишем

            • Tutorial

            TL;DR: GitHub://PastorGL/AQLSelectEx.


            Aerospike AQL SELECT


            Однажды, ещё не в студёную, но уже зимнюю пору, а конкретно пару месяцев назад, для проекта, над которым я работаю (нечто Geospatial на основе Big Data), потребовалось быстрое NoSQL / Key-Value хранилище.


            Терабайты исходников мы вполне успешно прожёвываем при помощи Apache Spark, но схлопнутый до смешного объёма (всего лишь миллионы записей) конечный результат расчётов надо где-то хранить. И очень желательно хранить таким образом, чтобы его можно было по ассоциированным с каждой строкой результата (это одна цифра) метаданным (а вот их довольно много) быстро найти и отдать наружу.

            И вот какая вышла история...
          • MongoDB Go Driver туториал

            Хорошие новости! Официальный драйвер go для mongoDB вышел в бета-версию. Немного поразмыслив я решил перевести статью с официального сайта mongoDB вместо того, чтобы писать материал самостоятельно. Вот что будет в этом туториале:


            • Установка mongo-go-driver
            • Соединение с mongoDB с помощью mongo-go-driver
            • Использование BSON объектов
            • Использование CRUD методов
              image
            Читать дальше →
          • DataGrip 2018.3: поддержка Cassandra, генерация SQL-файлов из объектов, много улучшений в автодополнении и многое другое

              Привет! Это рассказ о том, что нового в нашем плагине для баз данных. Мы выпускаем его, как отдельный продукт DataGrip, и поставляем почти во все другие наши IDE. Будет много картинок и гифок. Для тех, кому лень их смотреть:

              • Поддержка Cassandra
              • Создание SQL-файлов из объектов схемы
              • Новые инспекции
              • Много новых штук в автодополнении
              • Работа с источником данных через одно подключение
              • Новый поиск
              • Высококонтрастная цветовая схема

              Спасибо тем, кто пробует EAP-версии и сообщает в наш трекер о проблемах: это помогает не дотащить их до релиза :) Активные пользователи уже получили бесплатные подписки на год.

              image
              Читать дальше →
            • Самодокументированные микросервисы (ArangoDB + swagger)

                Поддержание документации к микросервисам в актуальном состоянии по прежнему требует предельной дисциплины при разработке, ну и больших трудозарат. Очень разумный подход к созданию документации предлагает, например, GraphQL, где документация неразрывно связана с программным кодом и этим гарантируется 100% соответствие документации и документируемых сервисов. Однако, непривычность подхода GraphQL для разработчиков, привыкших к REST-API, все еще затрудняет продвижение этой технологии в практическую разработку приложений. Тут же можно вспомнить и SOAP, который уже давно решил проблему соответствия документации и сервисов, но из-за переусложненности не прижился в широких массах разработчиков.

                Хотелось бы найти такой стек технологий для разработки микросервисов, который обеспечил такую же самодокументируемость программного кода при разработке «традиционных» REST-API микросервисов. И он, как оказалось, уже существует.
                Читать дальше →
              • Database as Сode. Копаем глубже


                  В IT-проектах код пишут все. Инженеры с помощью нескольких строк управляют Kubernetes кластерами, разгоняют облака Terraform'ом и ворочают тонны конфигураций на Ansible, Chef и Puppet. QA пишут понятные бизнесу тестовые сценарии на Spock и Cucumber. Аналитики свободно, часто лучше разработчиков, разговаривают на SQL. Проектная документация в форматах Markdown, AsciiDoc или LaTEX "компилируются" в нужный формат на билд-сервере. Ну а сами разработчики, эти укротители кода, владеют сразу россыпью языков на каждый жизненный случай — клиентский, серверный, скриптовый, функциональный и пр.


                  Код уже давно перестал быть загадочной тарабарщиной и теперь в том или ином виде доступен и понятен многим, даже премьер-министрам. И весь этот код участвует в стандартном жизненном цикле — находится под управлением VCS, подвергается code review, автоматизированному тестированию, CI, CD. Используются общие инструменты и подходы, метрики производительности и качества. А все вместе это носит гордое название — "Everything as code".


                  Однако мир БД традиционно стоит особняком вдалеке от этой феерии прогресса и технологий. Процесс разработки и сопровождения БД не меняется годами и продолжает вселять ужас и страх в разработчиков, администраторов и пользователей по всему миру. Но возможно ли представить БД в виде обычного кода? Приблизиться к основному процессу разработки, использовать общие инструменты и подходы? Об этом под катом.

                  Database as Code? Что за дичь?

                Самое читаемое