Рубрика «nosql» - 3

Немало баз данных на сегодняшний день стремятся сделать всё, чтобы обеспечить высокую производительность, масштабируемость и доступность, при этом минимизируя сложность и стоимость поддержки. Azure Cosmos DB — отличный пример СУБД, которая легко может обеспечить эти качества. Данная статья описывает её возможности вместе с ограничениями, которые могут быть неочевидными с первого взгляда и при этом стать серьезной проблемой в будущем, если их не учесть при проектировании системы.
Читать полностью »

в 11:46, , рубрики: nosql, redis

В серии из нескольких статей я приведу свой адаптированный перевод раздела Redis Best Practices с официального сайта Redis Labs.

Redis Best Practices, часть 1 - 1

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

Привет!

Продолжаем исследовать применимость принципов функционального программирования при проектировании ERP. В предыдущей статье мы рассказали зачем это нужно, заложили основы архитектуры, и продемонстрировали построение простых сверток на примере оборотной ведомости. По сути, предлагается подход event sourcing, но за счет разделения БД на иммутабельную и мутабельную часть, мы получаем в одной системе комбинацию преимуществ map / reduce-хранилища и in-memory СУБД, что решает как проблему производительности, так и проблему масштабируемости. В этой статье я расскажу (и покажу прототип на TypeScript и рантайме Deno), как в такой системе хранить регистры мгновенных остатков и рассчитывать себестоимость. Для тех, кто не читал 1-ю статью — краткое резюме:

1. Журнал документов. ERP, построенная на базе РСУБД представляет собой огромный мутабельный стейт с конкурентным доступом, поэтому не масштабируется, слабо-аудируема, и ненадежна в эксплуатации (допускает рассогласование данных). В функциональной ERP все данные организованы в виде хронологически-упорядоченного журнала иммутабельных первичных документов, и в ней нет ничего кроме этих документов. Связи разрешаются от новых документов к старым по полному ID (и никогда наоборот), а все остальные данные (остатки, регистры, сопоставления) являются вычисляемыми свертками, то есть кэшируемыми результами работы чистых функций на потоке документов. Отсутствие стейта + аудируемость функций дает нам повышенную надежность (блокчейн на эту схему прекрасно ложится), а бонусом мы получаем упрощение схемы хранения + адаптивный кэш вместо жесткого (организованного на базе таблиц).
Читать полностью »

Привет!

В этой статье мы попробуем взглянуть на архитектуру учетных систем (ERP, CRM, WMS, MES, B2B, ...) с позиций функционального программирования. Существующие системы сложны. Они базируются на реляционной схеме данных, и имеют огромный мутабельный стейт в виде сотен связаных таблиц. При этом единственным «источником правды» в таких системах является хронологически-упорядоченный журнал первичных документов (отпечатков событий реального мира), которые, очевидно, должны быть иммутабельными (и это правило соблюдается в аудируемых системах, где корректировки «задним числом» запрещены). Журнал документов составляет от силы 20% объема БД, а все остальное — промежуточные абстракции и агрегаты, с которыми удобно работать на языке SQL, но которые требуют постоянной синхронизации с документами, и между собой.

Если вернуться к истокам (устранить избыточность данных и отказаться от хранения агрегатов), а все бизнес-алгоритмы реализовать в виде функций, применяемых непосредственно к потоку первичных документов — мы получим функциональную СУБД, и построенную на ней функциональную ERP. Проблема производительности решается благодаря мемоизации, а объем функционального кода будет вполне соизмерим с объемом декларативного SQL, и не сложнее для понимания. В данной статье мы продемонстрируем подход, разработав простейшую файловую СУБД на языке TypeScript и рантайме Deno (аналог Node.js), а также протестируем производительность сверток на примере типичных бизнес-задач.

Почему это актуально

1) Мутабельный стейт + избыточность данных — это плохо, особенно когда необходимо обеспечивать его постоянную синхронизацию с потоком документов. Это источник потенциальных расхождений учетных данных (баланс не сходится) и трудно обнаруживаемых побочных эффектов.
Читать полностью »

Язык запросов Cypher изначально разработан специально для графовой СУБД Neo4j. Целью Cypher является предоставить человеко-читаемый язык запросов к графовым базам данных похожий на SQL. На сегодня Cypher поддерживается несколькими графовыми СУБД. Для стандартизации Cypher была создана организация openCypher.

Основы работы с СУБД Neo4j описаны в статье Основы работы с Neo4j в браузере.

Для знакомства с Cypher рассмотрим пример генеалогического дерева заимствованный из классического учебника по Прологу за авторством И. Братко. На этом примере будет показано как добавлять узлы и связи в граф, как им назначать метки и атрибуты и как задавать вопросы.

Генеалогическое дерево в Neo4j, отредактированный вид

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

Привет! Ранее мы опубликовали уже 3 статьи из 5 в нашей серии подборок интересных учебных курсов от Microsoft. Сегодня – уже четвертая часть, и в ней мы расскажем про самые свежие курсы по облаку Azure.

Кстати!

  • Все курсы бесплатные (вы даже сможете попробовать платные продукты бесплатно);
  • 5/6 на русском языке;
  • Начать обучение можно мгновенно;
  • По окончании вы получите бейдж об успешном прохождении обучения.

Присоединяйтесь, подробности под катом!

Все статьи из серии

Этот блок будет обновляться с выходом новых статей

  1. 7 бесплатных курсов для разработчиков
  2. 5 бесплатных курсов для IT-Администраторов
  3. 7 бесплатных курсов для архитекторов решений
  4. 6 самых свежих курсов по Azure
  5. ** самых ********** ****** от M******** на *******

6 самых свежих курсов по Azure - 1Читать полностью »

Руслан Ароматов, главный разработчик, МКБ

Умный сервис кэша на базе ZeroMQ и Tarantool - 1

Привет! Я работаю бэкенд-разработчиком в Московском кредитном банке, и за время работы у меня накопился некоторый опыт, которым я хотел бы поделиться с сообществом. Сегодня я расскажу, как мы писали свой собственный сервис кэша для фронт-серверов наших клиентов, использующих мобильное приложение «МКБ Онлайн». Статья может быть полезна тем, кто занимается проектированием сервисов и знаком с микросервисной архитектурой, in-memory базой данных Tarantool и библиотекой ZeroMQ. В статье практически не будет примеров кода и объяснения основ, а только описание логики работы сервисов и их взаимодействия на конкретном примере, работающем у нас на бою уже более двух лет.
Читать полностью »

Редактор блок схем — о дружбе Vue.js и MxGraph - 1

С чего все началось?

Я фронтенд разработчик, но стремлюсь к развитию, решил написать fullstack приложение и стать миллионером получить бесценный опыт.

Так вот, начал планировать бэкенд, выбрал MongoDB для хранения данных, и был готов планировать структуру и связи полей.

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

— Нет? Значит сделаю делов то, найти библиотеку и накидать интерфейс!
Fullstack идея была отодвинута на задний план и я начал проработку простейшего редактора схем БД.
— Наивный… – но это я понял немного позднее.
Читать полностью »

О том, что такое база KDB+, язык программирования Q, какие у них есть сильные и слабые стороны, можно прочитать в моей предыдущей статье и кратко во введении. В статье же мы реализуем на Q сервис, который будет обрабатывать входящий поток данных и высчитывать поминутно различные агрегирующие функции в режиме “реального времени” (т.е. будет успевать все посчитать до следующей порции данных). Главная особенность Q состоит в том, что это векторный язык, позволяющий оперировать не единичными объектами, а их массивами, массивами массивов и другими сложносоставными объектами. Такие языки как Q и родственные ему K, J, APL знамениты своей краткостью. Нередко программу, занимающую несколько экранов кода на привычном языке типа Java, можно записать на них в несколько строк. Именно это я и хочу продемонстрировать в этой статье.

Возможности языка Q и KDB+ на примере сервиса реального времени - 1Читать полностью »

Сайзинг Elasticsearch - 1

— How big a cluster do I need?
— Well, it depends… (злобное хихиканье)

Elasticsearch — сердце Elastic Stack, в котором происходит вся магия с документами: выдача, приём, обработка и хранение. От правильного количества нод и архитектуры решения зависит его производительность. И цена, кстати, тоже, если ваша подписка Gold или Platinum.

Основные характеристики аппаратного обеспечения — это диск (storage), память (memory), процессоры (compute) и сеть (network). Каждый из этих компонентов в ответе за действие, которое Elasticsearch выполняет над документами, это, соответственно, хранение, чтение, вычисления и приём/передача. Поговорим об общих принципах сайзинга и раскроем то самое «it depends». А в конце статьи ссылки на вебинары и статьи по теме. Поехали!
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js