Потребность в скорости: лучшее решение для базы данных

Question

Я хочу создать огромный индекс для еще большего набора данных. Данные представляют собой огромную коллекцию изображений (а я имею в виду миллионы фотографий!), И я хочу построить индекс для всех уникальных изображений. Поэтому я вычисляю значение хеш-функции каждого изображения и добавляю его к ширине, высоте и размеру файла изображения. Это создаст уникальный ключ для каждого изображения. Это будет сочетаться с местоположением изображения или местоположениями в случае дубликатов.

Технически говоря, это идеально поместится в одной таблице базы данных. Достаточно будет уникального индекса по имени файла и дополнительного неуникального индекса по hash-width-height-size. Тем не менее, я мог бы использовать существующую систему баз данных для решения этой проблемы или просто написать свою оптимизированную версию. В любом случае это будет однопользовательское приложение, и основная цель - обнаружить, когда я добавляю дубликат изображения в коллекцию, чтобы он предупредил меня о том, что оно уже есть в моей коллекции, и отобразил места, где находятся другие копии. Затем я могу решить добавить дубликат или удалить его.

Я уже писал реализации хеш-таблиц, и это не так сложно, если вы знаете, что вам нужно знать. Так что я мог бы просто реализовать свой собственный формат файла для этих данных. Маловероятно, что мне когда-нибудь понадобится добавить больше информации к этим изображениям, и меня не интересуют подобные изображения, только точные изображения. Я не храню оригинальные изображения в этом файле, просто хэш, размер и местоположение. Из опыта я знаю, что это может работать очень быстро. Я делал это раньше и уже почти три десятилетия занимаюсь подобными вещами, поэтому, скорее всего, я выберу это решение.

Но я удивляюсь ... Если вы сделаете то же самое с существующей системой баз данных, такой как SQL Server, Oracle, Interbase или MySQL, будет ли производительность все еще достаточно высокой? В этой базе данных будет проиндексировано около 750 ТБ изображений, что примерно равно 30 миллионам записей в одной маленькой таблице. Стоит ли задумываться об использовании обычной базы данных?

У меня есть сомнения по поводу удобства использования базы данных для этого проекта. Количество данных огромно, но структура очень проста. Мне не нужна многопользовательская поддержка или большинство других функций, которые предоставляет большинство баз данных. Поэтому я не вижу необходимости в базе данных. Но меня интересуют мнения других программистов по этому поводу. (Хотя я ожидаю, что большинство согласятся со мной здесь.)

---

Сам проект, который все еще является идеей в моей голове, должен быть неким инструментом или дополнением для проводника или чего-то еще. По сути, он создает индекс для любого внешнего жесткого диска, который я присоединяю к системе, и когда я копирую образ на этот диск где-то, он должен сказать мне, существует ли образ на этом диске. Это позволит мне избежать заполнения моих резервных дисков дубликатами, хотя иногда мне хотелось бы добавлять дубликаты. (Например, потому что они являются частью серии.) Поскольку я люблю создавать свои собственные визуализированные изображения, у меня есть много изображений. Кроме того, я делаю цифровые фотографии с цифровых камер с 1996 года, поэтому у меня также есть огромная коллекция фотографий. Добавьте к этому несколько других больших коллекций, и вы скоро поймете, что объем данных будет огромным. (И да, в моей коллекции уже много дубликатов ...)

Answer 1

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

Транзакционная согласованность, например, не тривиальна.

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

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

Существующие решения для баз данных, как правило, выигрывают, потому что у них были годы совершенствования и тонкой настройки, чтобы получить свои преимущества, наивная попытка, вероятно, будет медленнее, громче и будет делать меньше, в то время как Увеличение ваша загрузка разработки в чисто МОНУМЕНТАЛЬНЫХ пропорциях.

http://fetter.org/optimization.html

1. Первое правило оптимизации - вы не говорите об оптимизации.
2. Второе правило оптимизации - вы НЕ говорите об оптимизации.
3. Если ваше приложение работает быстрее, чем базовый транспортный протокол, оптимизация завершена.
4. Один фактор за раз.
5. Нет маркетроидов, нет расписаний маркетроидов.
6. Тестирование будет продолжаться столько, сколько потребуется.
7. Если это ваша первая ночь в Клубе оптимизации, вам нужно написать контрольный пример.

Кроме того, с базами данных есть одна вещь, которую вы совершенно ДОЛЖНЫ укоренить.

Скорость не важна

Ваши данные находясь там , когда вам это нужно, , что важно.

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

Хэши

Вы также сетуете на то, что будете использовать образы SHA / MD5 и т. Д. Для дедупликации изображений. Это само по себе ошибочное представление, хэши файлов могут только определить, отличаются ли файлы, а не совпадают ли они.

Логика сродни тому, чтобы попросить 30 человек подбросить монету, и вы видите, что первый получает головы, и, таким образом, решает удалить любого другого человека, который получает голову, потому что он, очевидно, один и тот же человек.

https://stackoverflow.com/questions/405628/what-is-the-best-method-to-remove-duplicate-image-files-from-your-computer

Хотя вы можете подумать, что вряд ли у вас будет 2 разных файла с одинаковым хешем, ваши шансы примерно такие же, как и выигрыш в лото. Шансы на то, что вы выиграете в лото, невелики, но кто-то выигрывает в лото каждый день. Не позволяй этому быть тебе.

Answer 2

Я только что проверил производительность PostgreSQL на своем ноутбуке (Core 2 Duo T5800 2,0 ГГц 3,0 ГБ RAM). У меня есть таблица с чуть более 100M записей, 5 столбцов и некоторые индексы. Я выполнил запрос диапазона для одного индексированного столбца (не первичного ключа) и вернул все столбцы. Средний запрос возвратил 75 строк и выполнен за 750 мс. Вы должны решить, достаточно ли это быстро.

Answer 3

Поскольку вы рассматриваете это однопользовательское приложение, я бы, вероятно, взглянул на SQLite . Я бы сказал, это должно соответствовать вашим требованиям.