Оптимальный способ хранения небольших растровых изображений. Объем > 400 Gb. БД или FS?

Question

[ryzhikovas]

Стоит задача хранения большого числа снимков поверхности Земли. Текущая реализация предполагает представления всей поверхности (за исключением приполярных областей) в проекции Меркатора. Этот виртуальный растр разбивается на фрагменты 256x256 - тайлы. Такое представление выполняется для каждого из предопределенных уровней масштабного представления.
На данный момент атрибутивная информация о снимках хранится примитивным образом с использованием SQLite. Для тайлов разработано хранилище на базе структуры каталогов ФС. Распределение по каталогам соответствует B-tree индексации (а-ля google maps, bing). Скорость получения фрагмента растра вполне устраивает. Однако много времени потратил на реализацию велосипедов - механизма транзакций, логгирования. Вопрос - насколько эффективно (в первую очередь под эффективностью здесь понимаю скорость выполнения операции выборки растровых данных) подобное можно было бы реализовать штатными средствами PostgreSQL / MySQL / ets? Какие особенности БД (кроме межпроцессного взаимодействия) снизят скорость чтения данных по сравнению с доступом к небольшим "сырым" файлам в ФС?

Answer 1

[Pavel K]

Конечно ФС!
Только тут главное правильно распределить это дело =)
Т.е. не в одну папку сразу скидывать все 400Гб, а например по каким либо критериям (хоть по названию, хоть как).
Упс, пардон за очевидность, не прогрузился пост до конца.

База ведь так же хранит эти файлы на диске, причём sqlite - одним файлом .
В тонкости не вникал, т.к. мал ещё, но мне было проще распределять по файлам, возможно какие-либо оптимизации помогут.
Использовал xfs.
Плюс ещё в том, что можно в несколько потоков спокойно отображение делать.

Но Вы, наверное, это и так знаете, скорее всего ответ для таких как я =)

Answer 2

[xmoonlight]

1. Пути к тайлам - в базе.
2. Картинки - в на диске с prefetching and caching в ОЗУ. По-скольку статика: nginx.
В принципе, нужно посчтитать: вполне возможно есть смысл при загрузке "холмы" (или всю матрицу тайлов) закинуть сразу в RAM-drive.
"Холмы": их вершины - это часто используемые тайлы. Как правило - это центры крупных городов (можно набрать статистикой использования).

Comments

[ryzhikovas]

Спасибо за совет (nginx). Пока надобности в нем нет (БД и единственный клиент в одной локальной сети). В дальнейшем, возможно, понадобится. На счет предварительной подгрузки максимально используемых тайлов - смысла нет, т.к. запрос любого фрагмента равновероятен (система используется для уточнении геопривязки поступающих снимков по текущему покрытию. Людей, которые рассматривают свои города, нет:) ). Упреждающее кэширование использую при просмотре карты.

[xmoonlight]

ryzhikovas: я бы посоветовал для Вашего случая держать процесс к БД с Persistent connection и через ORM писать и читать данные. Это будет значительно быстрее, чем сырые файлы в ФС.

[ryzhikovas]

Если есть время, объясните пожалуйста, за счет каких механизмов "значительно быстрее, чем сырые файлы в ФС". Речь сейчас про передачу по сети или про выборку с диска вообще? Если про работу в целом, то что мне при работе с файлами, что СУБД приходится читать данные с диска и в этом отношении скорость постоянна. Если вы имеете в виду выигрыш в скорости за счет кэширования в объектной БД - то это не совсем верно, т.к. зная логику формирования растра из тайлов я реализовал эффективное кэширование с учетом пространственной близости соседних по географическим координатам тайлов.

[xmoonlight]

ryzhikovas: ставьте пару-тройку SSD и туда все тайлы и конец обсуждению.

Answer 3

[lega]

Можно взять MongoDB, плюсы такие:
* При большой нагрузке или объеме можно будет данные разлить по шардингу. Это так же может помочь сэкономить, например можно вместо одного сервера DO за $480 можно взять 24 минимальных виртуалки за $120, + будет больше ядер и трафика.
* Можно хранить доп. параметры, теги, (атрибутивную информацию) и прочее вместе с файлом, таким образом тайл и все с ним связанное будет в одном блоке данных, в отличие от применения *sql. Это хорошо для производительности, т.к. меньше индексов и меньше обращений к ФС.
* Можно сделать доп. индексы
* Можно использовать гео-индексы, выборка тайлов по радиусу и т.п.
* Так же для данной задачи (вполне возможно) достаточно атомарных комитов, они лучше по производительности чем полноценные транзакции.

Comments

[ryzhikovas]

Спасибо, посмотрю.

[sim3x]

ryzhikovas:
если надумаете внедрять в продакшен монго стоит сравнить как оно в реальности себя ведет
https://events.yandex.ru/lib/talks/2324/
https://events.yandex.ru/lib/talks/2325/

[ryzhikovas]

sim3x: Большое спасибо

Answer 4

[zed]

Лично я склоняюсь к БД. Например, SQLite. Только, естественно, не одним файлом, а разбить на "блоки". Идею можно посмотреть в SAS.Планете (кэш BerkeleyDB) или в SACS, там прямо в SQLite есть кэш.

По поводу FS - не всякая система способна выдержать такую нагрузку (Windows XP и 50 миллионов файлов в кеше SASGIS), так что нужно смотреть на её тип и проверять под нагрузкой.

Если вопросов по надёжности FS не возникает и вы в ней уверены, то стоит рассмотреть вопрос бэкапов, а именно, удобство и скорость их создания и восстановления. Имхо, бэкапить миллионы тайлов очень неудобно, поэтому БД тут дадут фору.