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

На хабре не нашлось обзоров «более быстрой альтернативы Redis» — KeyDB. Получив достаточно свежий опыт его использования, хочется восполнить этот пробел.

KeyDB как [потенциальная] замена Redis - 1

Предыстория достаточно банальна: однажды с большим наплывом трафика была зафиксирована значительная деградация производительности приложения (а именно — времени ответа). На тот момент, к сожалению, не удалось провести нормальную диагностику происходящего, поэтому впоследствии запланировали ряд нагрузочных тестирований. После их проведения удалось обнаружить узкое место, коим стал кэш базы данных в Redis. Как это часто бывает, проблему нельзя было решить сию секунду и правильным путём — силами разработчиков (изменением логики работы). Поэтому включилось любопытство и желание побороть ситуацию обходным путём. Так и появилась эта статья.Читать полностью »

Привет.

Меня зовут Миша Бутримов, я хотел бы хотел немного рассказать про Cassandra. Мой рассказ будет полезен тем, кто никогда не сталкивался с NoSQL-базами, — у нее есть очень много особенностей реализации и подводных камней, про которые нужно знать. И если кроме Oracle или любой другой реляционной базы вы ничего не видели, эти вещи спасут вам жизнь.

Чем хороша Cassandra? Это NoSQL-база данных, cпроектированная без единой точки отказа, которая хорошо масштабируется. Если вам нужно добавить пару терабайт для какой-нибудь базы, вы просто добавляете ноды в кольцо. Расширить ее на еще один дата-центр? Добавляете ноды в кластер. Увеличить обрабатываемый RPS? Добавляете ноды в кластер. В обратную сторону тоже работает.

Cassandra. Как не умереть, если знаешь только Oracle - 1

В чем еще она хороша? В том, чтобы обрабатывать много запросов. Но много — это сколько? 10, 20, 30, 40 тысяч запросов в секунду — это немного. 100 тысяч запросов в секунду на запись — тоже. Есть компании, которые говорили, что они держат 2 млн. запросов в секунду. Вот им, наверное, придется поверить.

И в принципе у Cassandra есть одно большое отличие от реляционных данных — она вообще на них не похожа. И об этом очень важно помнить.
Читать полностью »

Немало баз данных на сегодняшний день стремятся сделать всё, чтобы обеспечить высокую производительность, масштабируемость и доступность, при этом минимизируя сложность и стоимость поддержки. 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 идея была отодвинута на задний план и я начал проработку простейшего редактора схем БД.
— Наивный… – но это я понял немного позднее.
Читать полностью »


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