Кто-либо использовал объектную базу данных с большим объемом данных?

Вы должны прочитать сценарии использования MongoDB . Люди, которые просто играют с технологиями, часто просто смотрят, как это работает, и еще не достигли той точки, где они могут понять ограничения. Для правильных типов наборов данных и шаблонов доступа 50 ГБ - это ничто для MongoDB, работающего на правильном оборудовании.

Эти нереляционные системы рассматривают компромиссы, которые допускают RDBM, и немного их меняют. Последовательность не так важна, как другие вещи в некоторых ситуациях, поэтому эти решения позволяют вам обменять это на что-то другое. В некоторых ситуациях компромисс по-прежнему составляет относительно небольшие миллисекунды или, возможно, секунды.

Также стоит прочитать о теореме CAP .

Вот несколько тестов на db4o:

http://www.db4o.com/about/productinformation/benchmarks/

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

MongoDB поддерживает SourceForge, The New York Times и несколько других крупных баз данных ...

Я искал возможность перенести API, который у меня точно есть, с приложением iphone для переполнения стека, которое я написал некоторое время назад, обратно в MongoDB, откуда он сейчас находится в MySQL. база данных. В необработанном виде дамп SO CC находится в диапазоне нескольких гигабайт, и способ, которым я построил документы для MongoDB, привел к базе данных 10G +. Можно утверждать, что я плохо сконструировал документы, но я не хотел тратить на это кучу времени.

Одна из самых первых вещей, с которой вы столкнетесь, если начнете идти по этому пути, - это отсутствие поддержки 32-битной версии. Конечно, сейчас все переходит на 64 бит, но нужно иметь в виду. Я не думаю, что какая-либо из основных баз данных документов поддерживает разбиение на страницы в 32-битном режиме, и это понятно с точки зрения сложности кода.

Чтобы проверить то, что я хотел сделать, я использовал 64-битный экземпляр узла EC2. Второе, с чем я столкнулся, это то, что, хотя на этой машине было 7 ГБ памяти, когда физическая память была исчерпана, все пошло с быстрой на не очень. Я не уверен, что у меня что-то было настроено неправильно на данный момент, потому что отсутствие поддержки 32-битной системы убило то, для чего я хотел ее использовать, но я все еще хотел увидеть, как это выглядит.Загрузка того же дампа данных в MySQL занимает около 2 минут на гораздо менее мощном компьютере, но сценарий, который я использовал для загрузки двух баз данных, работает по-разному, поэтому я не могу провести хорошее сравнение. Запуск только подмножества данных в MongoDB был намного быстрее, если в результате получилась база данных размером менее 7 ГБ.

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

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

Кто-то только что начал производство с 12 терабайтами данных в MongoDB. Самый большой, о котором я знал до этого, был 1 ТБ. Многие люди хранят действительно большие объемы данных в Mongo.

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

Когда я начинал db4o еще в 2000 году, я не имел в виду огромные базы данных. Ключевая цель заключалась в том, чтобы очень просто сохранить любой сложный объект с помощью одной строки кода и сделать это хорошо и быстро с низким потреблением ресурсов, чтобы его можно было запускать встраиваемым и на мобильных устройствах.

Со временем у нас появилось много пользователей, которые использовали db4o для веб-приложений и с довольно большими объемами данных, приближаясь к сегодняшнему максимальному размеру файла базы данных 256 ГБ (с сконфигурированным размером блока 127 байтов). Итак, чтобы ответить на ваш вопрос: да, db4o будет работать с 50 ГБ, но вы не должны планировать использовать его для терабайт данных (если вы не можете аккуратно разделить свои данные по нескольким базам данных db4o, затраты на установку для одной базы данных незначительны, вы можете просто вызвать #openFile ())

db4o был приобретен Versant в 2008 году, поскольку его возможности (встроенные, низкое потребление ресурсов, легкий вес) делают его отличным дополнительным продуктом к высокопроизводительному продукту Versant. база данных объектов VOD . VOD масштабируется для огромных объемов данных и работает намного лучше, чем реляционные базы данных. Я думаю, что он просто посмеется над 50 ГБ.

Возможно, стоит упомянуть.

Миссия Planck Европейского космического агентства работает на базе данных объектов Versant. http://sci.esa.int/science-e/www/object/index.cfm?fobjectid=46951

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

В любом случае, он создал 25 Тб информации, хранящейся в Versant и разбросанной по 3 континентам. Когда миссия завершится в следующем году, ее общий объем составит 50 Т

Возможно, стоит также отметить, что базы данных объектов, как правило, намного меньше, чтобы хранить ту же самую информацию. Это связано с тем, что они действительно нормализованы, нет дублирования данных для соединений, нет пустого бесполезного пространства столбцов и мало индексов, а не сотни. Вы можете найти публичную информацию о тестировании, которое проводила ESA, чтобы рассмотреть возможность хранения данных в многоколоночном формате реляционной базы данных по сравнению с использованием правильной объектной модели и хранением в объектной базе данных Versant. Они обнаружили, что могут сэкономить 75% дискового пространства, используя Versant.

Вот реализация: http://www.planck.fr/Piodoc/PIOlib_Overview_V1.0.pdf

Здесь они говорят о 3T - против 12T, обнаруженных при тестировании. http://newscenter.lbl.gov/feature-stories/2008/12/10/cosmic-data/

Также ... есть бенчмарки, которые показывают, что Versant на порядки быстрее на стороне анализа миссии.

Чирс, -Роберт