NoSQL *

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

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

Я вхожу в Tarantool Core Team и участвую в разработке движка базы данных, внутренних коммуникаций компонентов сервера и репликации. И сегодня расскажу, как устроена репликация.

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


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

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

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

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



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

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

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

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

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

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

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

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

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

UPD: туториал обновлен в связи с выходом релизной версии.

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

• Установка mongo-go-driver
• Соединение с mongoDB с помощью mongo-go-driver
• Использование BSON объектов
• Использование CRUD методов

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

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

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

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

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

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

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

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

Несколько месяцев назад на одной из ретроспектив мы решили попробовать совместное чтение.

Наш формат:

1. Выбираем книгу.
2. Определяем часть, которую необходимо прочитать за неделю. Выбираем небольшой объем.
3. В пятницу обсуждаем прочитанное.
4. Читаем в нерабочее время, обсуждаем в рабочее.
5. После окончания книги совместно выбираем следующую.

Что дает:

1. Мотивация на чтение и дочитывание.
2. Развитие скиллов (в том числе на будущее).
3. Выравнивание майндсета и терминологии в команде.
4. Рост доверия.
5. Лишний повод пообщаться.

Одна из недавних книг, которую мы читали — Designing Data-Intensive Applications. Да-да, та самая книга с кабанчиком. И эта книга настолько всем понравилась, что я решил сделать здесь обзор, чтобы большее количество людей ее прочитали.


Карта в исходном качестве

Это будет немного напыщенная речь, но меня действительно раздражает софт, в котором люди пытаются изобрести очередной собственный язык запросов. У нас уже есть триллион различных ORM, еще триллион баз данных с собственным языком запросов каждая, и еще триллион SaaS-продуктов, для доступа к которым нужно освоить какой-нибудь очередной DSL, которые они придумали.

Верните мне мой SQL обратно. Это язык понятный каждому, существует аж с 70-х и за это время успел стать стандартом. Он прост в чтении и может использоваться кем угодно, от бизнеса до инженеров.

Однако вместо этого мне приходится изучать целый ворох разных "garbage query language", потому что люди по-прежнему пытаются изобрести колесо заново.

Вы когда-нибудь анализировали вакансии?

Задавались вопросом, в каких технологиях наиболее сильна потребность рынка труда на текущий момент? Месяц назад? Год назад?

Как часто открываются новые вакансии Java-разработчиков в определенном районе Вашего города и как активно они закрываются?

В этой статье я расскажу Вам, как можно достичь желаемого результата и построить отчетную систему по интересующей нас теме. Поехали!


(Источник картинки)

В былые времена, когда веб разработка строилась на том, что серверные приложения направляли запросы в реляционные базы данных и выдавали на выходе HTML, часто встречался такой код:

// ВНИМАНИЕ: Плохой пример!
function popup(msg: string): string {
    return "<p class=\"popup\">" + msg + "</p>";
}

или такой:

// ВНИМАНИЕ: Плохой пример!
function getName(login: string): string {
    return "SELECT name FROM users WHERE login = \"" + login + "\"";
}

С тех пор мы научились использовать более безопасные подходы.

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

В этой статье я хотел бы поделиться своими соображениями об атаках путем внедрения кода. По всей видимости, они все еще представляют собой угрозу в JavaScript.

Добрый день! Меня зовут Данил Липовой, наша команда в Сбертехе начала использовать HBase в качестве хранилища оперативных данных. В ходе его изучения накопился опыт, который захотелось систематизировать и описать (надеемся, что многим будет полезно). Все приведенные ниже эксперименты проводились с версиями HBase 1.2.0-cdh5.14.2 и 2.0.0-cdh6.0.0-beta1.

1. Общая архитектура
2. Запись данных в HBASE
3. Чтение данных из HBASE
4. Кэширование данных
5. Пакетная обработка данных MultiGet/MultiPut
6. Стратегия разбивки таблиц на регионы (спилитинг)
7. Отказоустойчивость, компактификация и локальность данных
8. Настройки и производительность
9. Нагрузочное тестирование
10. Выводы

До недавнего времени в Одноклассниках около 50 ТБ данных, обрабатываемых в реальном времени, хранилось в SQL Server. Для такого объема обеспечить быстрый и надежный, да еще и устойчивый к отказу ЦОД доступ, используя SQL СУБД, практически невозможно. Обычно в таких случаях используют одно из NoSQL-хранилищ, но не всё можно перенести в NoSQL: некоторые сущности требуют гарантий ACID-транзакций.

Это подвело нас к использованию NewSQL-хранилища, то есть СУБД, предоставляющей отказоустойчивость, масштабируемость и быстродействие NoSQL-систем, но при этом сохраняющей привычные для классических систем ACID-гарантии. Работающих промышленных систем этого нового класса немного, поэтому мы реализовали такую систему сами и запустили ее в промышленную эксплуатацию.

Как это работает и что получилось — читай под катом.

Академическое проектирование хранилища данных рекомендует держать все в нормализованной форме, со связями между. Тогда накат изменений по реляционной математике даст надежное хранилище с поддержкой транзакций. Atomicity, Consistency, Isolation, Durability — вот это все. Иначе говоря, хранилище специально строится для безопасного обновления данных. Но оно вовсе не оптимально для поиска, особенно широким жестом по таблицам и полям. Нужны индексы, много индексов. Объемы разрастаются, запись замедляется. SQL LIKE не индексируется, а JOIN GROUP BY отправляет медитировать в планировщик запросов.

Elasticsearch, Kibana и Logstash (ELK) – отличный набор инструментов для сбора и визуализации большого количества данных.

Логи, журналы, события – всё это довольно легко собирается, мапится и отображается в едином инструментарии. Logstash мапит данные, Elasticsearch хранит их, а Kibana отображает в виде графиков.

При всей мощи этой связки, естественно, есть задачи, которые невозможно реализовать через встроенные возможности.

Например, Kibana прекрасно показывает данные в рамках одной таблицы (индекса), но как только дело доходит до объединения разных индексов в одну выборку, она беспомощно разводит руки.

И единственный способ решить задачу в этом случае – выгрузить данные из Kibana и объединить их в любом другом средстве, например, в Excel.

Простой пример. Представьте, что Ваша Ёлка (ELK) собирает и хранит события Jira – по любому изменению любой из задач таск-трекера.

В этом случае в индексе Elasticsearch по одной задаче будет храниться несколько записей:

13 Июня вышел Elasticsearch 6.3.0 на основе Lucene 7.3.0. Это последний стабильный релиз и уже доступен для использования в облаке через службу Elasticsearch на Elastic Cloud.

Tренду NoSQL уже почти 10 лет, и можно смело делать какие-то выводы и обобщения. Этим и займемся, поговорим про развитие NoSQL.

Вспомним, как родился NoSQL. Посмотрим, что в нем хорошо, а что плохо, и что выдержало испытание временем. Разберем возможности, которые уже есть в SQL, и которые теперь появляются в NoSQL СУБД. Выделим уникальные ценности NoSQL, и заглянем чуть-чуть вперед в то, что на рынке будет завтра.

А поможет нам в этом Константин Осипов (@kostja) — разработчик и архитектор СУБД Tarantool, который в своем докладе на РИТ++ 2017 говорил про тренды NewSQL, ведь архитектору полагается понимать, что происходит в мире баз данных, чтобы, как минимум, не изобретать велосипед.


О спикере: Сейчас Константин Осипов работает над Tarantool, но ранее участвовал в разработке MySQL, и, когда Константин начинал работу над новой базой данных, его очень смущало, зачем это делать вообще, зачем нужна очередная база данных. В частности, отношение к NoSQL было очень скептическим, как к «недоSQL».

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