Управление большим количеством данных и изображений в

Question

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

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

Что бы вы мне порекомендовали?

Тану очень

Answer 1

MySQL и даже SQLite уже имеют пространственные индексы, поэтому проблем здесь нет.

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

Чтобы легко перейти в хранилище объемом несколько терабайт, с самого начала планируйте использование нескольких серверов. Если данные в основном для чтения, простой способ - хранить изображения на разных хостах, каждый со статическим HTTP-сервером, и записи базы данных, где находится каждое изображение. затем поместите веб-интерфейс веб-приложения для базы данных, где URL-адреса каждого изображения напрямую указывают на соответствующий сервер хранения. Таким образом, вы можете продолжать добавлять хранилище, не создавая узких мест на «центральном» сервере.

Answer 2

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

(Если вы хотите получить доступ через Интернет, попробуйте Amazon Storage . Это не бесплатно, но очень дешево, и они поддерживают масштабируемость для вас.)

Answer 3

Postgresql , SQL Server 2008 и Все последние версии Oracle имеют пространственную индексацию, разбиение таблиц и BLOB-объекты и способны выполнять функцию обратного конец большой географической базы данных. Возможно, вы также захотите проверить два ГИС-приложения с открытым исходным кодом: GRASS и QGIS , которые могут поддерживать выполнение того, что вы хотите, с меньшими изменениями, чем при написании специального приложения. Оба могут использовать Postgresql и другие базы данных.

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

Answer 4

Еще одна предупреждающая заметка об использовании B / C / LOB, поскольку меня укусил экспоненциальный рост БД путем внутреннего хранения с БД.

Как насчет хранения ГИС-карт на отдельном сервере и просто сохранить LAT / LONG «форму» области с БД. ГИС может обновляться отдельно без затрат на хранение изображений в основной базе данных.

Меньше для администратора. Меньшая стоимость резервного копирования.

Answer 5

Использовать сервер изображений ESRI. Вам не понадобится база данных для обслуживания изображений. Его очень легко использовать. Он также работает с файлами и работает быстро и обрабатывает много форматов изображений. Кроме того, он выполняет обработку изображений на лету и поддерживает множество клиентов. AutoCAD, Microstation, ArcMap, ArcIMS, ArcServer ... и т. Д.

Сервер изображений

Answer 6

Несмотря на то, что вы не отвечаете критериям бесплатности, я настоятельно рекомендую вам использовать SQL Server 2008 из-за двух функций в этой версии, которые могут помочь:

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

• ГЕОГРАФИЧЕСКИЕ ТИПЫ ДАННЫХ - поддержка геопространственных (широта / долгота) типов данных, вероятно, будет очень полезна для вашего решения.

Удачи!