Рубрика «nosql»

Database as Сode. Копаем глубже - 1

В 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. Да-да, та самая книга с кабанчиком. И эта книга настолько всем понравилась, что я решил сделать здесь обзор, чтобы большее количество людей ее прочитали.

DDIA book (книга с кабанчиком) — сделай level up в понимании баз данных - 1
Карта в исходном качестве
Читать полностью »

Я не буду учить твой Garbage Query Language - 1

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

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

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

Читать полностью »

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

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

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

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

MongoDB и исследование рынка ИТ-вакансий - 1

Источник
Читать полностью »

В былые времена, когда веб разработка строилась на том, что серверные приложения направляли запросы в реляционные базы данных и выдавали на выходе 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.

Актуальна ли проблема инъекций в JavaScript? - 1
Читать полностью »

Добрый день! Меня зовут Данил Липовой, наша команда в Сбертехе начала использовать 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. Выводы

Читать полностью »

NewSQL=NoSQL+ACID - 1

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

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

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

Миграция данных ElasticSearch без потерь - 1

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

Читать полностью »

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

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

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

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

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

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

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

Где же у него кнопка?! Как простому человеку выгрузить данные из Kibana и Elasticsearch и не напрягать при этом разрабов - 1
Читать полностью »

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

Вышел Elasticsearch 6.3.0 - 1

Читать полностью »