В данной статье рассмотрим архитектуры простых и эффективных KV-хранилищ с использованием цепной репликации (chain replication), которая активно исследуется и успешно применяется в различных системах.
Читать полностью »
Рубрика «nosql» - 6
Chain replication: построение эффективного KV-хранилища (часть 1-2)
2018-11-19 в 11:26, admin, рубрики: algorithms, Chain replication, CRAQ, design, Distributed Databases, Eventual consistency, fault tolerance, FAWN, FAWN-DS, FAWN-KV, Geo-replication, Hibari, HyperDex, key-value store, nosql, reliability, Strong consistency, Алгоритмы, Анализ и проектирование систем, математика, Программирование, распределенные системыDatabase as Сode. Копаем глубже
2018-10-25 в 6:59, admin, рубрики: database, database as code, database tools, devops, infrastructure as code, nosql, sql, Администрирование баз данных, Блог компании КРОК
В IT-проектах код пишут все. Инженеры с помощью нескольких строк управляют Kubernetes кластерами, разгоняют облака Terraform'ом и ворочают тонны конфигураций на Ansible, Chef и Puppet. QA пишут понятные бизнесу тестовые сценарии на Spock и Cucumber. Аналитики свободно, часто лучше разработчиков, разговаривают на SQL. Проектная документация в форматах Markdown, AsciiDoc или LaTEX "компилируются" в нужный формат на билд-сервере. Ну а сами разработчики, эти укротители кода, владеют сразу россыпью языков на каждый жизненный случай — клиентский, серверный, скриптовый, функциональный и пр.
Код уже давно перестал быть загадочной тарабарщиной и теперь в том или ином виде доступен и понятен многим, даже премьер-министрам. И весь этот код участвует в стандартном жизненном цикле — находится под управлением VCS, подвергается code review, автоматизированному тестированию, CI, CD. Используются общие инструменты и подходы, метрики производительности и качества. А все вместе это носит гордое название — "Everything as code".
Однако мир БД традиционно стоит особняком вдалеке от этой феерии прогресса и технологий. Процесс разработки и сопровождения БД не меняется годами и продолжает вселять ужас и страх в разработчиков, администраторов и пользователей по всему миру. Но возможно ли представить БД в виде обычного кода? Приблизиться к основному процессу разработки, использовать общие инструменты и подходы? Об этом под катом.
DDIA book (книга с кабанчиком) — сделай level up в понимании баз данных
2018-10-08 в 6:22, admin, рубрики: ddiabook, nosql, sql, Администрирование баз данных, базы данных, распределенные системы, читаем вместе, Читальный залНесколько месяцев назад на одной из ретроспектив мы решили попробовать совместное чтение.
Наш формат:
1. Выбираем книгу.
2. Определяем часть, которую необходимо прочитать за неделю. Выбираем небольшой объем.
3. В пятницу обсуждаем прочитанное.
4. Читаем в нерабочее время, обсуждаем в рабочее.
5. После окончания книги совместно выбираем следующую.
Что дает:
1. Мотивация на чтение и дочитывание.
2. Развитие скиллов (в том числе на будущее).
3. Выравнивание майндсета и терминологии в команде.
4. Рост доверия.
5. Лишний повод пообщаться.
Одна из недавних книг, которую мы читали — Designing Data-Intensive Applications. Да-да, та самая книга с кабанчиком. И эта книга настолько всем понравилась, что я решил сделать здесь обзор, чтобы большее количество людей ее прочитали.
Я не буду учить твой Garbage Query Language
2018-09-10 в 6:49, admin, рубрики: db, nosql, orm, SaaS, sql, Анализ и проектирование систем, Программирование
Это будет немного напыщенная речь, но меня действительно раздражает софт, в котором люди пытаются изобрести очередной собственный язык запросов. У нас уже есть триллион различных ORM, еще триллион баз данных с собственным языком запросов каждая, и еще триллион SaaS-продуктов, для доступа к которым нужно освоить какой-нибудь очередной DSL, которые они придумали.
Верните мне мой SQL обратно. Это язык понятный каждому, существует аж с 70-х и за это время успел стать стандартом. Он прост в чтении и может использоваться кем угодно, от бизнеса до инженеров.
Однако вместо этого мне приходится изучать целый ворох разных "garbage query language", потому что люди по-прежнему пытаются изобрести колесо заново.
MongoDB и исследование рынка ИТ-вакансий
2018-09-07 в 13:49, admin, рубрики: data mining, etl, mongodb, nosql, python, sql, анализ данных, вакансииВы когда-нибудь анализировали вакансии?
Задавались вопросом, в каких технологиях наиболее сильна потребность рынка труда на текущий момент? Месяц назад? Год назад?
Как часто открываются новые вакансии Java-разработчиков в определенном районе Вашего города и как активно они закрываются?
В этой статье я расскажу Вам, как можно достичь желаемого результата и построить отчетную систему по интересующей нас теме. Поехали!
Актуальна ли проблема инъекций в JavaScript?
2018-09-02 в 20:08, admin, рубрики: javascript, nosql, Блог компании Поиск VPS, информационная безопасность, инъекция кодаВ былые времена, когда веб разработка строилась на том, что серверные приложения направляли запросы в реляционные базы данных и выдавали на выходе 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
2018-08-17 в 9:26, admin, рубрики: big data, Hadoop, Hbase, nosql, nosql базы данных, Блог компании Сбербанк, хранилища данныхДобрый день! Меня зовут Данил Липовой, наша команда в Сбертехе начала использовать HBase в качестве хранилища оперативных данных. В ходе его изучения накопился опыт, который захотелось систематизировать и описать (надеемся, что многим будет полезно). Все приведенные ниже эксперименты проводились с версиями HBase 1.2.0-cdh5.14.2 и 2.0.0-cdh6.0.0-beta1.
- Общая архитектура
- Запись данных в HBASE
- Чтение данных из HBASE
- Кэширование данных
- Пакетная обработка данных MultiGet/MultiPut
- Стратегия разбивки таблиц на регионы (спилитинг)
- Отказоустойчивость, компактификация и локальность данных
- Настройки и производительность
- Нагрузочное тестирование
- Выводы
NewSQL = NoSQL+ACID
2018-07-23 в 13:03, admin, рубрики: cassandra, nosql, Администрирование баз данных, базы данных, Блог компании Одноклассники, одноклассники.ru, распределенные системы
До недавнего времени в Одноклассниках около 50 ТБ данных, обрабатываемых в реальном времени, хранилось в SQL Server. Для такого объема обеспечить быстрый и надежный, да еще и устойчивый к отказу ЦОД доступ, используя SQL СУБД, практически невозможно. Обычно в таких случаях используют одно из NoSQL-хранилищ, но не всё можно перенести в NoSQL: некоторые сущности требуют гарантий ACID-транзакций.
Это подвело нас к использованию NewSQL-хранилища, то есть СУБД, предоставляющей отказоустойчивость, масштабируемость и быстродействие NoSQL-систем, но при этом сохраняющей привычные для классических систем ACID-гарантии. Работающих промышленных систем этого нового класса немного, поэтому мы реализовали такую систему сами и запустили ее в промышленную эксплуатацию.
Как это работает и что получилось — читай под катом.
Читать полностью »
Миграция данных ElasticSearch без потерь
2018-07-05 в 18:33, admin, рубрики: devops, elasticsearch, kaizen, nosql, open source, Администрирование баз данных, миграция данных
Академическое проектирование хранилища данных рекомендует держать все в нормализованной форме, со связями между. Тогда накат изменений по реляционной математике даст надежное хранилище с поддержкой транзакций. Atomicity, Consistency, Isolation, Durability — вот это все. Иначе говоря, хранилище специально строится для безопасного обновления данных. Но оно вовсе не оптимально для поиска, особенно широким жестом по таблицам и полям. Нужны индексы, много индексов. Объемы разрастаются, запись замедляется. SQL LIKE не индексируется, а JOIN GROUP BY отправляет медитировать в планировщик запросов.
Где же у него кнопка?! Как простому человеку выгрузить данные из Kibana и Elasticsearch и не напрягать при этом разрабов
2018-06-19 в 14:42, admin, рубрики: elasticsearch, elc, Excel, jira, kibana, nosql, open source, визуализация данных, выгрузка, конверсия, метрики, хранение данныхElasticsearch, Kibana и Logstash (ELK) – отличный набор инструментов для сбора и визуализации большого количества данных.
Логи, журналы, события – всё это довольно легко собирается, мапится и отображается в едином инструментарии. Logstash мапит данные, Elasticsearch хранит их, а Kibana отображает в виде графиков.
При всей мощи этой связки, естественно, есть задачи, которые невозможно реализовать через встроенные возможности.
Например, Kibana прекрасно показывает данные в рамках одной таблицы (индекса), но как только дело доходит до объединения разных индексов в одну выборку, она беспомощно разводит руки.
И единственный способ решить задачу в этом случае – выгрузить данные из Kibana и объединить их в любом другом средстве, например, в Excel.
Простой пример. Представьте, что Ваша Ёлка (ELK) собирает и хранит события Jira – по любому изменению любой из задач таск-трекера.
В этом случае в индексе Elasticsearch по одной задаче будет храниться несколько записей:
