Хранилища ключей-значений для средних и больших значений

У нас есть система, которая хранит (однозначные) миллионы изображений размером от 8 КБ до 500 КБ, в среднем около 15 КБ, в среднем 30 КБ. Общий объем данных в настоящее время составляет около 100 ГБ. Мы хотим получить доступ к изображению на основе хэша изображения (его можно изменить, но он должен вычисляться из изображения, чтобы эффективно проверять, находится ли изображение уже в хранилище данных). — изображения обрабатываются таким образом, что два изображения идентичны попиксельно, если и только если они идентичны побайтно). Настойчивость (очевидно) важна.

На данный момент мы храним их все как файлы внутри каталога — список каталогов кэшируется ядром, а фактическое чтение файлов выполняется по мере необходимости. Насколько я понимаю, основное преимущество хранилищ ключей и значений (по сравнению с использованием файловой системы как единой) заключается в чтении меньших значений, поскольку можно кэшировать всю страницу, а не только одно значение. Весь доступ в настоящее время осуществляется с веб-сервера (в интрасети) на том же сервере, что и данные, хотя мы можем перейти к проверке наличия ключей с удаленных компьютеров (в основном подключенных через 10GbE).

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

Учитывая рабочую нагрузку, чтение которой в основном (одиночное) чтение в порядке вставки и случайный (хотя, вполне возможно, повторный) доступ к произвольным ключам, в дополнение к частым операциям записи (что-то порядка величины 1:10 запись:чтение), вероятно ли будет большим преимуществом перехода к хранилищу ключей-значений из файловой системы?


person gsnedders    schedule 18.11.2011    source источник
comment
Это зависит от вашей текущей системы. Если он монолитный (один компьютер обслуживает запросы из одного места хранения), вы можете увидеть преимущество, добавив несколько узлов и сохранив копии данных ближе к клиентам, которые их потребляют. Чтобы сформулировать ответ, вам нужно будет подробно описать состав вашей текущей системы и указать, какие ваши текущие узкие места необходимо устранить.   -  person GalacticJello    schedule 22.11.2011
comment
Файл размером 2 КБ настолько отличается, что файлы размером 10 МБ w.r.t. накладные расходы метаданных/каталога. Чтение файла размером 2 КБ с диска проще, метаданные ограничены и ограничены поиском, а файлы размером 10 МБ, где основное время - это фактическая потоковая передача. Не могли бы вы рассказать немного больше о распределении размера файла? Являются ли небольшие файлы нормой или файлы среднего размера?   -  person dmeister    schedule 23.11.2011
comment
проверьте Microsoft Sharepoint для такого рода работы, это может удовлетворить ваши потребности. В этом случае нет необходимости изобретать велосипед   -  person Alex    schedule 25.11.2011


Ответы (4)


В зависимости от

  • количество файлов
  • как вы их структурируете на FS
  • какую ФС вы используете
  • какое хранилище вы используете

у вас могут закончиться inodes, или у вас может быть медленное время доступа к файлам снова (например, если вы поместите слишком много записей в один каталог).

Вы также должны уделить немного внимания атомарному доступу к файлам (и/или созданию каталогов), в то время как хранилище KV обычно позаботится об этом за вас.

У меня были проблемы со всеми этими вещами в прошлом с подходами fs-as-key-value-store :).

Но это можно сделать, см., например, Bigdis, который является реализацией протокола redis KV в виде файлов на диске, из сам автор redis, но вы должны быть немного осторожны со своими операциями.

В зависимости от вашей проблемы вы можете найти MogileFS или прямой облачный S3, которые будут лучшими решениями.

person riffraff    schedule 26.11.2011

Резюме: Для ваших требований к целостности данных, сохранению, размеру и скорости я рекомендую Redis.

Прекрасную вводную презентацию можно увидеть здесь:
https://simonwillison.net/static/2010/redis-tutorial/

Примечание. Дополнительная информация не помешала бы, но на основе того, что вы дали + что я знаю, вот некоторые из основных игроков:

Memcached:
https://memcached.org/
Бесплатный , с открытым исходным кодом, высокопроизводительная система кэширования объектов с распределенной памятью, хорошо подходит для ускорения динамических веб-приложений.
+ хорошо подходит для веб-приложений, бесплатно, с открытым исходным кодом.
- если сервер выходит из строя (сбой процесса memcached или перезагрузка системы), все сеансы теряются. Ограничения производительности на более высоких (коммерческого использования) уровнях.

Redis:
https://redis.io/
Аналогично memcached, но с сохраняемостью данных, поддерживает несколько типов значений, счетчики с атомарным увеличением/уменьшением и встроенным сроком действия ключа.
+ сохраняет данные на диск, чтобы они никогда не терялись, очень просто, быстро, гибко ( ключи могут содержать строки, хэши, списки, наборы и отсортированные наборы), сегментирование, поддерживаемое vmware, а не отдельным лицом.
- ограниченная кластеризация.

LevelDB:
https://google-opensource.blogspot.com/2011/07/leveldb-fast-persistent-key-value-store.html
Быстрый механизм хранения ключей и значений, написанный в Google. который сопоставляет строковые ключи со строковыми значениями.
+ Google.
- ?возможно с Google + ;)

TokoyoCabinet:
https://fallabs.com/tokyocabinet/< br> Включает поддержку блокировки, транзакций ACID, типа данных двоичного массива.
+ Скорость и эффективность.
- Менее известен в некоторых областях, например нас

Проект Волдеморт:
https://project-voldemort.com/
Расширенное хранилище ключей и значений, написанное на Java. Обеспечивает контроль параллелизма нескольких версий (MVCC) для обновлений. Обновления реплик выполняются асинхронно, что не гарантирует непротиворечивости данных.
+ Функциональность
- Непротиворечивость

MongoDB:
https://www.mongodb.org/< br> Масштабируемая, высокопроизводительная, ориентированная на документы база данных с открытым исходным кодом. Написано на C++, включает репликацию и высокую доступность с зеркалами в локальных и глобальных сетях и автоматическим сегментированием. Популярен в сообществе Ruby on Rails.
+ Простая установка, хорошая документация, поддержка.
- Относительно новый.

Диван:
http://www.couchdb.org/< br> Аналогичен Mongo, предназначен для баз данных документов.
+ репликация, расширенные запросы.
- кластеризация, управление дисковым пространством.

Cassandra:
https://cassandra.apache.org/< br> Apache Cassandra отличается отказоустойчивостью и децентрализованностью и используется, в частности, в Netflix, Twitter и Reddit.
+ Кластеризация и репликация.
- Подробнее нужны знания по настройке.

Я не могу предоставить все ссылки из-за нехватки времени, но надеюсь, что это, по крайней мере, поможет.

person Michael Durrant    schedule 25.11.2011

Вы предоставляете слишком мало информации, чтобы дать конкретный ответ - таким образом, только некоторые аспекты, относящиеся к тому, что вы описываете:

  • целостность данных
    Это может быть что угодно - т.е. несанкционированное изменение данных должно быть запрещено и/или, по крайней мере, любой такой инцидент должен быть обнаружен... ИЛИ это может быть просто что-то из области "RAID и/или резервное копирование.. .".

  • "идентичные изображения"
    файлы изображений содержат несколько полей/областей метаданных... ваш метод приводит к тому, что два попиксельно идентичных изображения выглядят как разные, если у одного есть метаданные, а у другого нет (или какое-то поле метаданных отличается) ... это то, что вы хотите ?
    Еще один аспект в этой области - формат файла (PNG, BMP, JPEG и т. д.) и сжатие... одно и то же изображение, другой формат и/или алгоритмы сжатия (даже без потерь, такие как ZIP по сравнению с LZW, хуже с JPEG и т. д.) может привести к тому, что одно и то же изображение будет классифицировано как другое - это то, что вы хотите?

  • "сотни тысяч изображений" и "2 КБ - 10 МБ"
    это мало что говорит... т.е. каково среднее значение по сравнению со средним размером изображения/файла?

  • access
    Является ли доступ к этим файлам/изображениям распределенным (как в CDN)? Или это по локальной сети?

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

Без какой-либо дополнительной и действительно конкретной информации я бы посчитал любую статистику/контрольный показатель/рекомендацию в лучшем случае удачным выстрелом.

Возможные решения включают, например, распределенную систему (может быть на основе файловой системы/памяти/БД) и/или хранилище на основе SSD, и/или RAID, и/или SAN и т. д.

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

person Yahia    schedule 23.11.2011
comment
Я должен согласиться с тем, что целостность данных была слишком расплывчатой: на самом деле единственное, что меня беспокоит, это то, что данные, полученные из хранилища ключей и значений, совпадают с теми, которые были помещены. Идентичные изображения были упомянуты в вопрос (они обрабатываются так, что они попиксельно идентичны, они побайтно идентичны). В противном случае вопрос теперь касается остальных. - person gsnedders; 27.11.2011
comment
@gsnedders спасибо за дополнительную информацию ... даже с миллионами изображений я не понимаю, как KeyValueStore может принести какую-либо пользу ... чего вы ожидаете от KeyValueStore конкретно? - person Yahia; 27.11.2011

Если ваши данные меньше 1 ТБ, возможно, вам не нужна высокодоступная база данных NoSQL, а для большинства баз данных NoSQL требуется, чтобы данные хранились в оперативной памяти. Могу ли я предложить использовать стандартную реляционную БД и создать таблицу с хешем в качестве первичного ключа и большим двоичным объектом с вашими данными? Вы будете удивлены, насколько хорошо он работает, и вам не нужно беспокоиться об исчерпании инодов.

Если ваши данные являются текстовыми/сжимаемыми, реляционная база данных еще лучше. По моему опыту, немногие базы данных NoSQL будут сжимать данные за вас, вы должны делать это на стороне клиента. Но MySQL/MariaDB предлагают прозрачное сжатие.

Другой вариант — RocksDB. В некоторых случаях это очень полезно для дискового пространства, поскольку поддерживает сжатие zstd с пользовательским словарем.

person rjh    schedule 25.12.2019