динамично горизонтальное масштабируемое хранилище значения ключа

Вы слишком многого требуете от программного обеспечения с открытым исходным кодом.

Если в вашем бюджете есть пара сотен тысяч долларов на программное обеспечение корпоративного класса, есть несколько решений. Ничто не будет делать то, что вы хотите из коробки, но есть компании, у которых есть продукты, близкие к тому, что вы ищете.

"Быстрый (поэтому позволит выполнять запросы поверх него)"

Если у вас есть хранилище ключей и значений, все должно работать очень быстро. Однако проблема заключается в том, что без онтологии или схемы данных, построенной поверх хранилища ключей и значений, вы в конечном итоге будете просматривать всю базу данных для каждого запроса. Вам нужен индекс, содержащий ключ для каждого «типа» данных, которые вы хотите сохранить.

В этом случае вы обычно можете выполнять запросы параллельно ко всем примерно 15 000 компьютерам. Узким местом является то, что дешевые жесткие диски ограничиваются 50 операциями поиска в секунду. Если ваш набор данных помещается в ОЗУ, ваша производительность будет чрезвычайно высокой. Однако, если ключи хранятся в ОЗУ, но недостаточно ОЗУ для хранения значений, система будет переходить на диск почти при каждом поиске значений ключа. Каждый ключ расположен в произвольном месте на диске.

Это ограничивает вас до 50 запросов ключ-значение в секунду на сервер. Принимая во внимание, что когда пары ключ-значение хранятся в оперативной памяти, нет ничего необычного в том, чтобы получить 100 000 операций в секунду на сервер на обычном оборудовании (например, Redis).

Однако скорость последовательного чтения дисков чрезвычайно высока. У меня поиск дисков достигает 50 МБ/с (800 МБ/с) при последовательном чтении.Таким образом, если вы храните значения на диске, вам необходимо структурировать хранилище таким образом, чтобы значения, которые необходимо прочитать с диска, можно было считывать последовательно.

Вот в чем проблема. Вы не можете получить хорошую производительность в ванильном хранилище ключ-значение, если вы не храните пары ключ-значение полностью в ОЗУ (или ключи в ОЗУ со значениями на SSD-накопителях) или если вы определяете какой-либо тип схемы или тип system поверх хранилища. ключи, а затем сгруппировать данные на диске, чтобы все ключи данного типа можно было легко получить с помощью чтения последовательного диска.

Если ключ имеет несколько типов (например, если у вас есть отношения наследования типов данных в базе данных), то ключ будет элементом нескольких индексных таблиц. В этом случае вам придется пойти на компромисс между временем и пространством, чтобы структурировать значения, чтобы их можно было последовательно считывать с диска. Это влечет за собой хранение избыточных копий значения для ключа.

То, что вам нужно, будет немного более продвинутым, чем хранилище «ключ-значение», особенно если вы собираетесь выполнять запросы. Однако проблема хранения больших файлов не является проблемой. Представьте, что ваша система может использовать ключи размером до 50 мегабайт. Затем вы просто разбиваете файл размером 1 гигабайт на сегменты по 50 мегабайт и связываете ключ со значением каждого сегмента. Используя простой сервер, можно легко преобразовать часть файла, которую вы хотите, в операцию поиска значения ключа.

Проблема достижения избыточности является более сложной. Очень легко «создать код» или «разделить файл» таблицы «ключ-значение» для сервера, чтобы данные сервера можно было реконструировать со скоростью передачи данных (1 Гбит/с) на резервный сервер, если конкретный сервер умирает.Обычно вы можете обнаружить смерть сервера с помощью системы «сердцебиения», которая срабатывает, если сервер не отвечает в течение 10 секунд. Возможен даже поиск ключ-значение в таблицах ключ-значение, закодированных частью файла, но это неэффективно, но все же дает вам резервную копию на случай сбоя сервера. Более серьезные проблемы, почти невозможно поддерживать резервную копию в актуальном состоянии, а данные могут быть 3-минутными. Если вы выполняете много операций записи, функция резервного копирования приведет к некоторой нагрузке на производительность, но эта нагрузка будет незначительной, если ваша система в основном выполняет операции чтения.

Я не являюсь экспертом по поддержанию непротиворечивости и целостности базы данных в режимах сбоя, поэтому я не уверен, какие проблемы может вызвать это требование. Если вам не нужно об этом беспокоиться, это значительно упрощает конструкцию системы и ее требования.

Быстрая (поэтому позволит выполнять запросы поверх нее)

Во-первых, забудьте о объединениях или любых операциях, которые масштабируются быстрее, чем n*log(n), когда ваша база данных настолько велика. Есть две вещи, которые вы можете сделать, чтобы заменить функциональность, обычно реализуемую с помощью объединений. Вы можете либо структурировать данные, чтобы вам не нужно было выполнять соединения, либо вы можете «предварительно скомпилировать» запросы, которые вы делаете, и сделать компромисс между временем и пространством, предварительно вычислить соединения и сохранить их для поиска заранее. .

Для семантических веб-баз данных, я думаю, мы увидим, как люди предварительно компилируют запросы и идут на компромиссы между временем и пространством, чтобы добиться достойной производительности даже на наборах данных скромного размера.Я думаю, что это может быть сделано автоматически и прозрачно серверной частью базы данных без каких-либо усилий со стороны разработчика приложения. Однако мы только начинаем видеть корпоративные базы данных, реализующие эти методы для реляционных баз данных.Насколько мне известно, ни один продукт с открытым исходным кодом не делает этого, и я был бы удивлен, если бы кто-то еще пытался сделать это для связанных данных в горизонтально масштабируемых базах данных.

Для этих типов систем, если у вас есть дополнительная оперативная память или место для хранения, лучше всего использовать их для предварительного вычисления и сохранения результатов общих подзапросов из соображений производительности, вместо добавления дополнительной избыточности к ключу-значению. хранить. Предварительно вычислите результаты и упорядочите их по ключам, к которым вы собираетесь запрашивать, чтобы превратить соединение n ^ 2 в поиск по журналу (n). Любой запрос или подзапрос, который масштабируется хуже, чем n*log(n), требует выполнения и кэширования результатов в хранилище ключ-значение.

Если вы выполняете большое количество операций записи, кэшированные подзапросы будут признаны недействительными быстрее, чем они смогут быть обработаны, и прироста производительности не будет. Еще одна неразрешимая проблема — аннулирование кеша для кешированных подзапросов. Я думаю, что решение возможно, но я его не видел.

Добро пожаловать в ад. Вы не должны ожидать, что получите такую ​​систему бесплатно еще 20 лет.

Пока кажется, что не существует базы данных или хранилища значений ключей, которые бы соответствовали упомянутым мною критериям, даже после предложения вознаграждения в 100 баллов ответ на вопрос не был получен!

Вы просите чуда. Подождите 20 лет, пока у нас не появятся чудесные базы данных с открытым исходным кодом, или вы должны быть готовы платить деньги за решение, адаптированное к потребностям вашего приложения.