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

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

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

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

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

Ответ 1

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

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

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

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

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

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

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

Ответ 2

Резюме: для ваших требований целостности данных, постоянства, размера и скорости я рекомендую 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, который отображает строковые ключи в строковые значения.
+ Гугл.
-? можно с гуглом +;)

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

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

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

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

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

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

Ответ 3

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

целостность данных
Это может быть что угодно - то есть неавторизованное изменение данных должно быть запрещено и/или, по крайней мере, любой такой инцидент может быть обнаружен... ИЛИ это может быть просто что-то в области "RAID и/или резервное копирование...".
"идентичные изображения"
файлы изображений содержат несколько полей/областей метаданных... ваш метод приводит к тому, что два пиксельно-пиксельных идентичных изображения отличаются друг от друга, если у вас есть метаданные, а другие нет (или другое поле метаданных отличается)... это то, что вы хотите?
Другим аспектом в этой области является формат файла (PNG и BMP в сравнении с JPEG и т.д.) И сжатие... то же изображение и различные алгоритмы формата и/или сжатия (даже без потерь, такие как ZIP против LZW, что хуже с JPEG и т.д.) Может привести к классифицировать одно и то же изображение как другое - это то, что вы хотите?
"сотни тысяч изображений" и "2 КБ - 10 МБ"
это не говорит много... то есть средний размер изображения/файла среднего и среднего размера?
доступ Доступен ли доступ к этим файлам/изображениям (например, в CDN)? Или он основан на локальной сети?

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

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

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

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