Управляйте большими объемами данных и изображений в
мой вопрос похож на вопрос другого друга, размещенного здесь ... мы пытаемся разработать приложение, которое поддерживает, возможно, терабайты информации на основе земельного кадастра в Парагвае с изображениями и обычными данными.
Проблема в том, что мы хотим снизить стоимость эксплуатации до минимума, потому что это похоже на конкуренцию между компаниями, и по этой причине мы хотим использовать бесплатную базу данных .... Я прочитал много информации об этом но я все еще в замешательстве. Мы должны понимать, что люди, которые собираются использовать его, являются государственными служащими, поэтому одновременно с БД должно быть легко управлять.
Что бы вы порекомендовали мне?
Тану очень нравится
Кроме того, база данных обычно не используется в качестве интерфейса для «конечных пользователей», чтобы они могли управлять данными. Это неправильное представление Access. ;) Независимо от того, что вы выберете, вы должны создать подходящий интерфейс для своих пользователей.
Ответы 6
Все Postgresql, SQL Server 2008 и Любая последняя версия Oracle имеют пространственное индексирование, секционирование таблиц и большие двоичные объекты и могут выступать в качестве серверной части большой географической базы данных. Вы также можете попробовать два приложения ГИС с открытым исходным кодом: ТРАВА и QGIS, которые могут поддерживать выполнение того, что вы хотите, с меньшими усилиями по модификации, чем написание специального приложения. Оба могут использовать Postgresql и другие серверные части базы данных.
Что касается поддержки, любая коммерческая база данных или база данных с открытым исходным кодом потребует внимания компетентного администратора баз данных, если вы хотите, чтобы она хорошо работала с базами данных терабайтного размера. Я не думаю, что вам сойдет с рук модель чистой поддержки конечных пользователей - попытки сделать это вряд ли сработают.
Несмотря на то, что вы не соответствуете вашим критериям бесплатности, я настоятельно рекомендую вам рассмотреть возможность использования SQL Server 2008 из-за двух функций Gfeatures в этой версии, которые могут помочь:
FILESTREAM - позволяет хранить двоичные изображения в файловой системе, а не в самой базе данных. Это сделает вашу базу данных намного более управляемой, но при этом позволит вам запрашивать данные обычным способом.
ТИПЫ ГЕОГРАФИЧЕСКИХ ДАННЫХ - поддержка типов геопространственных данных (широта / долгота) может оказаться очень полезной для вашего решения.
Удачи!
<a href="msdn.microsoft.com/en-gb/librarybb964711.aspx"> Географические типы MSDN </a> Помогает с сохранением географического местоположения, но вам нужен 2008, который не выполняет часть запроса.
MySQL и даже SQLite уже имеют пространственные индексы, так что проблем нет.
Для хранения файлов данных вы можете использовать поле BLOB, но обычно гораздо лучше (и его легче оптимизировать) хранить в виде файлов. Чтобы сохранить файлы, связанные с записями БД, вы можете либо поместить полный путь (или URL) в поле varchar, либо сохранить изображение в пути, вычисленном по идентификатору записи.
Чтобы легко масштабироваться до многотерабайтного хранилища, с самого начала спланируйте использование нескольких серверов. Если данные в основном предназначены для чтения, простой способ - хранить изображения на разных хостах, каждый со статическим HTTP-сервером, и в записях базы данных, где находится каждое изображение. затем поместите интерфейс веб-приложения для базы данных, где URL-адреса для каждого изображения напрямую указывают на соответствующий сервер хранения. Таким образом, вы можете продолжать добавлять хранилище, не создавая узких мест на «центральном» сервере.
Похоже, файлы изображений займут значительную часть вашего хранилища. Не храните их в базе данных, просто сохраните информацию о местоположении файла в базе данных.
(Если вам нужен доступ через Интернет, попробуйте Хранилище Amazon. Это не бесплатно, но очень дешево, и они обеспечивают масштабируемость за вас.)
Еще одно предостережение об использовании B / C / LOB, поскольку меня укусил экспоненциальный рост БД за счет внутреннего хранения в БД.
Как насчет хранения карт ГИС на отдельном сервере и просто сохранения LAT / LONG "формы" области с / в БД. ГИС можно обновлять отдельно без затрат на хранение изображений в основной базе данных.
Меньше для админа. Меньше затрат на резервное копирование.
Используйте сервер изображений ESRI. Вам не понадобится база данных для обслуживания изображений. Его очень легко использовать. Он также быстро работает с файлами и поддерживает множество форматов изображений. Кроме того, он выполняет обработку изображений на лету и поддерживает множество клиентов. AutoCAD, Microstation, ArcMap, ArcIMS, ArcServer и т. д.
Вопрос довольно расплывчатый. Что вас беспокоит в первую очередь?