Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, gandjustas, Вы писали:
G>>Вовсе нет. Во многом даже проще, чем трахаться со скорость. записи в общее хранилище. Только прочитать сразу данные не сможешь.
CK>И как это решает пролему latency? Throughput — да, согласен, можно батчингом на клиенте заниматься. Но это ломает crush recovery и латентность увеличивает.
А есть эта проблема?
Вообще подходы такие:
1) Нужно часто читать и нечасто записывать (типичное приложение) — используем кэш
2) Нужно часто записывать и нечасто читать (ака логи, репортинг) — примитивный сторедж на запись (локальный диск) и асинхронная постобработка
3) Нужно часто читать и писать отдельные куски (соцсети) — разбиваем модель данных на маленькие несвязанные кусочки, кусочки держим и обновляем в кеше, при записи или изолируем IO кусочков (шардинг, разные диски) или применяем метод из 2
4) Нужно часто писать и читать агрегированные данные — stream processing, то есть держим в памяти данные для агрегации, пишем только агрегаты.
Я так понимаю, что мы про пункт №2 сейчас
CK>>>Но пока ты хранишь inprocess — приходят новые данные и ты не можешь их записать, пока не запишешь то что хранишь inprocess. Легко может наступить ситуация, когда у тебя память кончится до того как ты все запишешь.
G>>Тогда и распределенной базы будет та же проблема.
CK>Может конечно. Но тут есть варианты всегда, в тот же HBase можно писать данные так, чтобы нагрузка равномерно распределялась по regionserver-ам. Для этого нужно правильную схему выбрать, вот и вся сложность.
Опять для простой задачи — "как бы сделать так, чтобы весь поток данных записывался за ограниченное время в случаях отказа\недоступности серверов бд" вы пытаетесь продать решение, которое требует еще несколько серверов. Это приведет или к замедлению за счет кворума или к потере согласованности, что хуже, чем иногда давать клиенту ответ "сейчас не могу, попробуй позже".
CK>>>К тому же, если мы говорим о веб системах, то ты там тупо не сможешь ничего в памяти держать, так как у тебя на каждый запрос создается новый процесс и весь стейт в БД.
G>>Ты точно делал веб-сервисы? По процессу на запрос это сильно.
CK>Так работает apache с mod_php в prefork MPM режиме. На каждый http реквест запускается новый процесс. Соотв. весь стейт живет в БД и всяких мемкешах и прочих редисах. Я участвовал в разработке веб портала с милионной аудиторией в одной очень известной российской компании. 
Вас никто не заставляет также делать. Пользуйтесь нормальными серверами. IIS например и нормальными базами — SQL Server, а не mysql.
Сразу количество проблем с РСУБД и вебом поубавится и всякие "леворезьбовые" технологии не понадобятся.
CK>>>И да и нет. Если записи просто изменят значение, то да, будет конфликт. Но ты можешь использовать CRDT и просто добавить данные на обоих нодах, а потом слить все вместе.
G>>Давай подробный сценаий кто к кому и вкакой момент обращается.
CK>Ты делаешь чекаут и проводишь оплату внутренней валютой. Транзакция не уменьшает баланс, а добавляет операцию в список операций над твоим балансом, commit транзакции выполняется через консенсус (Paxos например). Такое можно нарулить на кассандре, например.
Не так быстро:
1) У тебя есть две ноды, которые асинхронно реплицируют данные и в любой момент может потеряться любое количество пакетов между узлами и клиентами.
2) У тебя есть приложение, которое в момент чекаута добавляет проводку в базу
3) Ты хочешь чтобы транзакция проходила всегда
4) Ты пытаешься добавить проводку сразу в две ноды
5) Но вторая нода оказывается недоступна, там баланс не меняется.
6) В этот же момент с друого сервера приложений отправляется аналогичная команда на снятие внутренней валюты, но для нее теперь певая нода недоступно
7) Получается у тебя две ноды, на одной баланс -50, на второй -70
8) Но на счете всего было 100 до начала двух транзакций.
CAP в этом случае не обманешь. AP системы не подходят для хранения важных данных (которые нельзя исказить, потерять, нарушить инварианты) в принципе. Прикладные механизмы разрешения конфликтов не помогут, ты можешь конфликт обнаружить позже, чем будет принято решение на основании неверных данных.
CK>>>Это если нет автоскейлинга, заранее известен состав клас
тера и машины добавляются в него ручками.
G>>Автоскейлинг мешает знать состав кластера?
CK>Не мешает, просто автоскейлинг означает не только то, что машины могут добавляться в кластер автоматически, но и то, что они оттуда могут точно также выбывать. Допустим у нас 3 машины. Моргнула сеть, машина (мастер), живущая в отдельной стойке, стала недоступна. Но так как этого "не может быть" (система построена из расчета что сеть абсолютно надежна и partition-ов не бывает) система должна решить что эта машина умерла, правильно? И что она в этом случае делает? Логично выбрать нового мастера из оставшихся двух живых и считать что старый мастер покинул кластер (кластер теперь состоит из двух машин). При этом временно изолированный на отдельной стойке мастер продолжает считать себя мастером, недоступные две оставшиеся машины он считает покинувшими кластер (автоскейлинг же).
Нет, node majority не так работает. Было 9 машин, сеть разделилась на 5 и 4. Там где 4 — не будет кворума, кластер не поднимется.
G>>Зависит от конфигурации. Чаще всего синхронная readable реплика. В Always on таких может быть две.
CK>Ну т.е. обычный master-slave без шардинга.
Да. По сути единственно рабочий вариант. Все multimnaster системы страдают от нарушения согласованности, чего в большинстве случаев допускать нельзя.
Шардинг это вообще не про доступность, а про деление нагрузки на разные физические узлы. В случае субд не нужно, они масштабируются путем добавления дисков, а не серверов.
G>>По странному стечению обстоятельств в большинстве случаев использования той же монги её можно было заменить postgres без потери каких либо качеств для программы.
CK>Ну монга это вообще булшит, понятно что постгрес лучше. Единственный плюс монги — простота развертывание и настройки, поэтому ее в основном используют для всяких мелких CRUD-ов.
Тем не менее самая массовая NoSQL база.
