Нужно хранить много данных на устройстве Android, подумав о том, чтобы пойти на OODB

Question

В настоящее время я работаю над проектом, основанным на Android. Не вдаваясь во многие детали, программное обеспечение будет работать на пользовательском устройстве. Аппаратное обеспечение никогда не изменится и всегда будет таким же. Это определенно плюс :)

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

Мы стремимся использовать объектно -ориентированную базу данных, что -то вроде DB4O или NEODATIS. Мы надеемся, что, сохраняя объекты, мы можем избавиться от наших отношений на уровне строк и хранить их на объекте (как ООП). Проблема в том, что мы не смогли найти никаких критериев, связанных с производительностью (по крайней мере, не недавних) этих, работающих и используемых на Android.

У кого -нибудь есть опыт работы с OODBS на Android и/или хранение и доступ к этому большому количеству данных? Если это так, любой совет, который вы могли бы дать, будет очень признателен.

-- Редактировать

Вот пример проблемы, с которой мы сталкиваемся. Это не связано с нашим приложением (мой NDA говорит, что я не могу опубликовать ничего конкретного), но этот пример хорошо представляет проблему.

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

автомобиль

id | Цвет | Make_id | in_toll_lane | model_id

делать

id | название

модель

id | имя | make_id

car_person

id | возраст | секс | is_driver | car_id

toll_lanes

id | cars_in_line | Ideal_cars_in_line | Ideal_occupants

Эти данные часто меняются. Это также станет довольно огромным, так как нет никаких сомнений, что многие люди ехали по Нью -Джерси в любой момент времени.

С этими данными мы должны иметь возможность сделать снимок по требованию любого, кто ездит на щуке. Мы также должны иметь возможность сделать снимок всех мужчин, которые водят, или всех женщин на магистрали. Мы также должны быть в состоянии искать по возрасту, полу, марки, модель и т. Д.

Теперь представьте, что нам нужно выяснить, в какую плату за дорожку должна входить каждый автомобиль, исходя из количества людей в автомобиле, идеального количества пассажиров, количества автомобилей, уже в очереди и идеальное количество автомобилей, которые должны быть в очереди Анкет

Это очень простой пример, хотя и довольно представитель нашей проблемы.

- конец редактирования

Заранее спасибо!

Answer 1

Вот некоторые наблюдения, хотя я подозреваю, что это не поможет вам напрямую.

Я думаю, что основные вопросы: собираетесь ли вы обнаружить свои сложные отношения с помощью логики времени выполнения приложения, поскольку события генерируют или изменяют данные, или вам придется просто сбросить данные в хранилище, а затем обнаружите неограниченные отношения с помощью запроса?

Если ваша бизнес -логика заполнит модель, вы можете легко создавать модели на основе ваших различных ссоров модели данных, например, в том, что все автомобили, имеющие драйверы мужского/женского пола. В этом случае, в основном, ваши отношения полустатические редко меняются (в то время как значения данных на другом конце этих отношений, вероятно, сильно меняются). Если это так, то зачем пытаться сохранить данные в технологии базы данных, которая заставляет вас постоянно пересматривать отношения (соединение). Это просто пустая трата процессора, и вы увидите плохую производительность, поскольку модель станет сложной. Таким образом, как только вы ответите на эти вопросы, будет очень ясно, если ODB или RDB - лучший выбор.

Теперь возникает вопрос, что будет работать на Android и обрабатывать огромные данные? Здесь я думаю, что я не могу помочь. Я работаю в Versant, у которого есть (DB4O и Versant) ODB. Теперь DB4O будет работать на Android, но на самом деле это правильный выбор для огромных данных ... Нет. Нет, если у вас нет очень изолированных данных, которые могут быть в отдельных базах данных и доступны только в изоляции, и это не звучит для меня, как будто это ваше ситуация Наша другая база данных, Versant, не значит обрабатывать огромные данные почти в режиме реального времени, но только клиент на 100% Java, сервер написан на C, поэтому он не будет работать на Android.

Я думаю, что вам нужно будет провести некоторое исследование, чтобы увидеть, у кого есть ODB, который может обрабатывать огромные данные на Android.

Лучший, -Robert

Answer 2

Вы не говорите много о ваших потребностях доступа к данным или на загрузке данных.

Если у вас есть 3 -метровые основные ряды, а затем куча небольших листовых столов, то вы можете просто преуспеть, кэшируя все столы листьев в оперативной памяти и «соединяя» к ним вручную. Многие системы имеют очень маленькие листовые таблицы (особенно по сравнению с основными данными), поэтому загрузка их в оперативную память, а затем просто смотреть их, когда вы загружаете ряд, может быть большой победой.

Очевидно, вы не делаете этого с основными отношениями с родителями-> дочерними отношениями, но если вы можете устранить соединения листьев, то чтение станет единственным соединением между родителем и ребенком, а не с полдюжины к родителям, ребенку и таблицам листьев Анкет

Даже если это не работает для всех таблиц листьев, если это работает для подавляющего большинства, этого вполне может быть достаточно, чтобы пережить вас над горбом.

Answer 3

Выступая для DB4O: мы проведем все наши регрессионные тесты на Android, потому что мы думаем, что это станет очень важной платформой для DB4O.

DB4O работает очень хорошо для порядка 3 миллионов объектов.

Мы проводим контрольное тестирование по другим базам данных на http://www.polepos.org/ И мы скоро выпустим новую версию теста, где мы запустим сложную настройку, также против SQLLITE. Перенос теста в Android также является соображением.

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

Ваше приложение звучит интересно. Если вам нужна помощь в оценке DB4O, просто крикните мне.

Answer 4

Джейсон: Для достижения любого участника DB4O вы должны использовать этот шаблон: FirstName @ db4o.com Best!