ZODB в памяти?

Question

В настоящее время я работаю над большим проектом (количество активных участников составляет около сотни K), и я был сильно склонен к решениям Plone.

Я задал несколько вопросов, связанных с этим, таких как здесь и здесь .

Получил несколько ответов от очень опытных Plonistas (и активных стековых потоков). Я очень ценю это. Люди продолжают говорить, что Plone плохо масштабируется до такой большой величины, и большинство причин - из-за ZODB.

Тогда я думаю о памяти в памяти для ZODB. Оперативная память действительно дешево сейчас! вы можете получить 128 ГБ всего за ~ 3 тыс. долл. США, в десять раз больше, чем обычный твердотельный накопитель на 128 ГБ за 300 долл., и достичь пропускной способности ввода-вывода ~ 30 ГБ по сравнению с ~ 300 МБ накопителя SSD.

Бэкэнд в памяти + Blob для двоичного диска + 10-секундный журнал для резервного копирования + все отмены, кроме последних 10-ти, будут уничтожением экземпляра! Они должны курить RDBM и предлагать полное сопоставление ACID + Transaction + Object в сравнении с такой кушеткой * / redis и т. Д.

Это технически возможно? Есть ли реализация? Стоит ли реализовывать (на ваш взгляд)?

Answer 1

Существует опция memcache для RelStorage, которая помогает, когда вам нужно использовать медленную базу данных, но на самом деле вам, вероятно, следует просто оставить такой тип кэширования в вашей операционной системе и убедиться, что на вашем сервере баз данных достаточно оперативной памяти.(Если объем ОЗУ достаточно большой, то в кеше файловой системы уже должно храниться большинство данных.)

SSD значительно сократит задержки чтения в худшем случае при произвольном доступе к данным, которых еще нет в кеше файловой системы.Кажется глупым не использовать их сейчас, тем более, что твердотельный накопитель Intel 330 настолько дешев и имеет конденсатор, эквивалентный рейд-контроллеру с батарейным питанием (что делает запись также очень быстрой.)

Решение для оперативной памяти никогда не может бытьрассматривается как ACID, так как он не будет долговременным.

Как уже упоминалось в моем комментарии к вашему другому посту, проблема здесь не в ZODB, а в синхронном использовании Plone единственного утверждаемого portal_catalog.

Answer 2

Вместо того, чтобы хранить весь ZODB в памяти, вы можете смонтировать portal_catalog в отдельной точке монтирования и сохранить его в памяти.Я уже видел такую ​​конфигурацию, и она работает без проблем примерно для 8 тысяч пользователей, использующих стандартное оборудование (2 сервера + 1 сервер Zeo).Это может быть достаточно для ваших нужд, возможно, с использованием более производительного hw.