Нужно хранить много данных на Android-устройстве, думая о выходе OODB - PullRequest
11 голосов
/ 01 декабря 2010

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

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

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

- Правка

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

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

car

id |цвет |make_id |in_toll_lane |model_id

make

id |имя

модель

id |имя |make_id

car_person

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

toll_lanes

id |cars_in_line |ideal_cars_in_line |ideal_occupants

Эти данные будут часто меняться.Это также собирается стать довольно огромным, поскольку нет никаких сомнений, что МНОГИЕ люди ездят вниз по NJ Pike в любой момент времени.

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

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

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

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

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

Ответы [ 4 ]

3 голосов
/ 01 декабря 2010

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

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

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

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

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

Best, -Robert

3 голосов
/ 01 декабря 2010

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

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

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

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

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

3 голосов
/ 01 декабря 2010

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

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

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

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

2 голосов
/ 02 декабря 2010

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

...