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

Ответ 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", которую вы заинтересовали, может быть актуальной, но в большинстве случаев обработка этого количества изображений, с которыми я столкнулся с таким магазином, не добавит никакой уникальной функции (а в некоторых случаях даже будет больно).