Большой, высокопроизводительный объект или хранилище ключей / значений для HTTP, обслуживающего Linux

У меня есть сервис, который обслуживает изображения для конечных пользователей с очень высокой скоростью, используя простой HTTP. Размер изображения варьируется от 4 до 64 Кбайт, и их общее количество составляет 1 300000000. Размер набора данных составляет около 30 ТБ, а изменения (новые объекты, обновления, удаления) составляют менее 1% запросов. Количество запросов пр. второй колеблется от 240 до 9000 и разбросан почти по всему, с немногими объектами, которые являются особенно "горячими".

На данный момент эти изображения представляют собой файлы в файловой системе ext3, распределенные только для чтения на большом количестве серверов среднего уровня. Это создает несколько проблем:

  • Использование файловой системы очень неэффективно, так как размер метаданных большой, кэш inode/dentry изменчив в Linux, и некоторые демоны имеют тенденцию stat()/readdir() проходить через структуру каталогов, что в моем случае становится очень дорогим.
  • Обновление набора данных занимает много времени и требует перемонтирования между наборами A и B.
  • Единственная разумная обработка - это работа на блочном устройстве для резервного копирования, копирования и т. Д.

То, что я хотел бы, является deamon, который:

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

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

1 ответ

Не существует волшебного решения для ваших нужд. База данных noSQL на самом деле не поможет; вам нужно принять некоторые основные решения относительно архитектуры вашего приложения.

и некоторые демоны, как правило, stat()/readdir() проходят через структуру каталогов

Перемещение данных в любую базу данных не поможет, если только эти демоны не будут считывать данные в первую очередь. Не проще ли перенастроить их или отключить?

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

Индекс должен оставаться в памяти

Если у вас есть 1,3 миллиарда записей, каждая с, скажем, 300 байтами метаданных, вам потребуется около 6 ГБ памяти. Большинство из которых никогда не будет доступно, но будет препятствовать доступу памяти для кэширования контента.

кэш inode/dentry изменчив в Linux

Вы пробовали настроить его?

Другие вопросы по тегам