Большая часть автомасштабирования nosql сталкивается с проблемой из-за того, что данные должны быть перенесены во время пиковой нагрузки. Что, если данные хранятся в общем хранилище, таком как CLVM, у которого меньше накладных расходов (по сравнению с NFS или общей файловой системой). Теперь, если каждый сегмент / сегмент представляет собой отдельный LVM, и вычисление может монтировать один или несколько LVM в зависимости от количества сегментов, за которые он отвечает. При высокой нагрузке вычислительные ресурсы откажутся от нескольких шардов (umount LVM), а новые вычислительные ресурсы, которые возникнут, будут монтировать шарды. Это разделяет проблемы хранения и вычислений БД и может сделать вычисления масштабируемыми по горизонтали. Я знаю, что serverfault не принимает открытых обсуждений. Предложение форума для публикации этого тоже мне поможет. Если кто-нибудь может помочь мне разобраться в подводных камнях этой идеи, тоже приветствую
Что, если данные хранятся в общем хранилище, таком как CLVM, которое имеет меньше накладных расходов ... Это разделяет проблемы хранения и вычислений БД и может сделать вычисления горизонтально масштабируемыми. ... Предложение форума для публикации этого тоже мне поможет. Если кто-нибудь может помочь мне разобраться в подводных камнях этой идеи, тоже приветствую.
Если только объем вычислений увеличен, по сути, по сравнению с ним уменьшено все, кроме задержки. Вы можете в конечном итоге обменять масштабирование вычислений на уменьшение масштаба дискового ввода-вывода (узкое место), но вы можете согласиться с компромиссом и можете добавить дополнительные более быстрые диски, чтобы избежать этого; дополнительное шасси обеспечивает много места.
Ссылаться на: "Сайт DB-Engine","DataStax's - Объяснение репликации данных в базах данных NoSQL","Linux Journal - хранилище высокой доступности с HA-LVM" и "Википедия: горизонтальное / вертикальное / масштабирование базы данных"веб-страницы для получения дополнительной информации.
Есть такие решения как MemCached (БД) которые легче добавить, чем переключиться с NoSQL на другое программное обеспечение, но программное обеспечение, обещающее лучшее масштабирование, является лучшим решением.
В этом сравнении Casandra против MongoDB Вердикт такой: «Если вам нужна масштабируемость записи и 100% доступность, то Cassandra вам больше подойдет». Всегда будут какие-то компромиссы, вам нужен полный анализ затрат и выгод, который учитывает деньги и время - худшая ситуация - пойти в одну сторону и зайти в тупик, вынудив повторно подойти к проблеме, когда та же самая или другая стена попал.
Вам решать, должно ли решение быть недорогим в краткосрочной или долгосрочной перспективе, и какой набор функций (сложность) соответствует вашим потребностям и стоит вашего времени. Первый сайт, указанный выше, предоставляет средства для сравнения различных наборов функций и стоимости, а также предоставляет ссылки на множество сайтов.
Позвольте мне предложить другой путь, распределенная разделяемая память или рефлексивная память.
"Система с распределенной памятью, часто называемая мультикомпьютером, состоит из нескольких независимых узлов обработки с модулями локальной памяти, которые соединены общей сетью межсоединений. Программные системы DSM могут быть реализованы в операционной системе или как программная библиотека и могут быть рассматриваются как расширения базовой архитектуры виртуальной памяти. При реализации в операционной системе такие системы прозрачны для разработчика; это означает, что основная распределенная память полностью скрыта от пользователей. В отличие от программных систем DSM, реализованных в библиотеке или уровень языка не прозрачен, и разработчикам обычно приходится программировать их по-другому. Однако эти системы предлагают более переносимый подход к реализациям системы DSM. Распределенная система с общей памятью реализует модель с общей памятью в системе с физически распределенной памятью ".
Наряду с программным решением для общей памяти существует также аппаратное решение. Вот несколько поставщиков распределенных вычислений интерфейсные платы:
Дельфин - Хост / целевой адаптер PXH812 - Подключает шину PCIe одного компьютера к другому со скоростью 64 Гбит / с с задержкой 138 наносекунд по меди на расстоянии до 5 метров (200 с оптоволокном). Это прозрачный версии (программное обеспечение не требуется, любая ОС и может смешивать арки ЦП), есть также хост-адаптер PXH810 NTB (непередаваемый мост) с API-интерфейсом Shared-Memory Cluster Interconnect (SISCI), но ОС ограниченное в: Windows, Linux, VxWorks или RTX. Смотрите их "Отражающая память PCI Express" страница интернета.
Кертисс-Райт - SCRAMNet GT200 - двухпортовая память появляется на шине хоста как дополнительная память хоста. Хост считывает и записывает данные через один порт, а сеть записывает данные в память через второй порт. Данные, записанные в память хостом, автоматически передаются оборудованием всем узлам в сети.
Абако - Интерфейсная карта PCIE-5565RC - Совместно использует 128 или 256 МБ SDRAM в Linux, VxWorks или Windows. Доступны интерфейсные карты для PCI Express, PMC, PCI и VME.
Наряду с платой за плату вы можете добавить концентратор к большинству перечисленных выше продуктов и добавить от нескольких до 256 узлов. Возможно, стоит подождать до следующего года и PCIe 4.0.
В MongoDB, например, есть концепция набор реплик для этой ситуации. В этом случае несколько экземпляров MongoDB обслуживают одни и те же данные. Если один выйдет из строя, другие продолжат обслуживание данных. Совместное хранилище не требуется или нежелательно для набора реплик; каждый экземпляр MongoDB хранит отдельную копию данных.
Это полностью ортогонально сегментированию, при котором данные разделяются между различными экземплярами MongoDB или наборами реплик.