разные есть требования. Вот тотже ZK не дает строгую консистентность по умолчанию, а кассандра может терять данные, как показано в тех тестамх из-за clock skew.

но это не значит совсем, что эти базы не нужны

Ну, zk не база, а хранилище блокировок. А Кассандра - скорее не нужна, да )

в ЗК есть разные типы znode.

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

Кстати, да, тоже источник информации ( https://jepsen.io/analyses )

А что у него с горизонтальным масштабированием? Он, если не ошибаюсь, с 11 версии (может даже раньше) шардируется даже без Citus, через партиционирование + FDW (в доке об этом пишут не очевидно, но я знаю ребят, которые так делали).

Не знаю, партиционирование есть, а вот про ядра-память нет ничего, вроде

Через FDW. Пара примеров:
- https://pgdash.io/blog/postgres-11-sharding.html
- https://about.gitlab.com/handbook/engineering/development/enablement/database/doc/fdw-sharding.html
- https://wiki.postgresql.org/wiki/WIP_PostgreSQL_Sharding#FDW_Based_Enhancements

Ну и старый способ через Citus тоже пока еще актуален:
- https://www.citusdata.com/blog/2018/01/10/sharding-in-plain-english/
- https://github.com/citusdata/citus

А, да, они же FDW оптимизировали. Странная и непростая замена RAC, но зато бесплатно )
При том, что я терпеть не могу RAC - вообще круто

Ну PG сейчас да, выбор по умолчанию

Всем спасибо за советы!

У нас так в воронку попадают ордера.
Дистрибьютор может в ордере что угодно расписывать, из-за чего сотрудникам отдела, который принимал эти заявки приходилось разгребать всё руками.

Мы подключили автоматизацию, которая сопоставляла пришедшие данные с данными в бд. И там учитываются как сокращения в названиях компаний/адресах/..., так и ошибки, в которых учитывался допуск (1-3 знака) и разные окончания (например, если использовалось множественное число). Если всё совпало, то можно процессить ордер, иначе - в ручной разбор.

Чтобы проверить качество можно прогнать алгоритм через старые закрытые ордера по входящим данным и сравнить результат с тем, что запроцессилось раньше.
Всегда остаётся определённый % не верного результата, но он минимален.

Также параллельно вычищали мусор из базы данных и делали более удобным и простым оформление ордера на стороне дистрибьютора. По возможности добавляли им доступ к идентификаторам (внешним), которые позволяли точно идентифицировать пользователя.

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

Надеюсь вам этот опыт поможет.

@mxsmirnov 👆

Недавно задумался, почему Redis не взял Raft и не сделал кластер на нём?
Начал изучать вопрос и оказалось, что Yossi Gottlieb (главный архитектор RedisLab) в 2018 именно это и начал делать под названием RedisRaft.
А в июне 2020 они прошли тесты Jepsen с которым помогает Kyle Kingsbury - https://jepsen.io/analyses/redis-raft-1b3fbf6
Это будет логичным шагом для нормального горизонтального масштабирования redis
https://redislabs.com/blog/redisraft-new-strong-consistency-deployment-option/

а сейчас как у них кластер работает ? там же есть репликация...

простыми словами он не обеспечивает 100% консенсус данных по кластеру

Коллеги! Вы все невероятно умные, талантливые и перспективные! Поздравляю всех с Наступающим Новым годом от имени коллег из своего техдирского канала @ctorecords! Дзынь 🥃 🍾🥳

Задуматься к новому году?