Здравствуйте, gandjustas, Вы писали:
G>Вовсе нет. Во многом даже проще, чем трахаться со скорость. записи в общее хранилище. Только прочитать сразу данные не сможешь.
И как это решает пролему latency? Throughput — да, согласен, можно батчингом на клиенте заниматься. Но это ломает crush recovery и латентность увеличивает.
CK>>Но пока ты хранишь inprocess — приходят новые данные и ты не можешь их записать, пока не запишешь то что хранишь inprocess. Легко может наступить ситуация, когда у тебя память кончится до того как ты все запишешь.
G>Тогда и распределенной базы будет та же проблема.
Может конечно. Но тут есть варианты всегда, в тот же HBase можно писать данные так, чтобы нагрузка равномерно распределялась по regionserver-ам. Для этого нужно правильную схему выбрать, вот и вся сложность.
CK>>К тому же, если мы говорим о веб системах, то ты там тупо не сможешь ничего в памяти держать, так как у тебя на каждый запрос создается новый процесс и весь стейт в БД.
G>Ты точно делал веб-сервисы? По процессу на запрос это сильно.
Так работает apache с mod_php в prefork MPM режиме. На каждый http реквест запускается новый процесс. Соотв. весь стейт живет в БД и всяких мемкешах и прочих редисах. Я участвовал в разработке веб портала с милионной аудиторией в одной очень известной российской компании.
CK>>И да и нет. Если записи просто изменят значение, то да, будет конфликт. Но ты можешь использовать CRDT и просто добавить данные на обоих нодах, а потом слить все вместе.
G>Давай подробный сценаий кто к кому и вкакой момент обращается.
Ты делаешь чекаут и проводишь оплату внутренней валютой. Транзакция не уменьшает баланс, а добавляет операцию в список операций над твоим балансом, commit транзакции выполняется через консенсус (Paxos например). Такое можно нарулить на кассандре, например.
CK>>Это если нет автоскейлинга, заранее известен состав кластера и машины добавляются в него ручками.
G>Автоскейлинг мешает знать состав кластера?
Не мешает, просто автоскейлинг означает не только то, что машины могут добавляться в кластер автоматически, но и то, что они оттуда могут точно также выбывать. Допустим у нас 3 машины. Моргнула сеть, машина (мастер), живущая в отдельной стойке, стала недоступна. Но так как этого "не может быть" (система построена из расчета что сеть абсолютно надежна и partition-ов не бывает) система должна решить что эта машина умерла, правильно? И что она в этом случае делает? Логично выбрать нового мастера из оставшихся двух живых и считать что старый мастер покинул кластер (кластер теперь состоит из двух машин). При этом временно изолированный на отдельной стойке мастер продолжает считать себя мастером, недоступные две оставшиеся машины он считает покинувшими кластер (автоскейлинг же).
G>Зависит от конфигурации. Чаще всего синхронная readable реплика. В Always on таких может быть две.
Ну т.е. обычный master-slave без шардинга.
G>По странному стечению обстоятельств в большинстве случаев использования той же монги её можно было заменить postgres без потери каких либо качеств для программы.
Ну монга это вообще булшит, понятно что постгрес лучше. Единственный плюс монги — простота развертывание и настройки, поэтому ее в основном используют для всяких мелких CRUD-ов.
