Нужно хранить много данных на Android-устройстве, думая о выходе OODB
В настоящее время я работаю над проектом, который основан на Android. Не вдаваясь в подробности, программное обеспечение будет работать на специально созданном устройстве. Аппаратное обеспечение никогда не изменится и всегда будет одинаковым. Это несомненный плюс:)
С учетом вышесказанного, этот проект требует от нас сохранения нагрузок и загрузок данных на устройстве - более 3 м строк в некоторых таблицах. SQLite прекрасно справляется со сканированием такого количества строк, и проблема возникает, когда мы начинаем делать сложные объединения, чтобы вернуть все необходимые данные. Мы думали о денормализации базы данных, но боимся, что это вытолкнет базу данных за пределы области использования.
Мы рассматриваем использование объектно-ориентированной базы данных, что-то вроде db4o или NeoDatis. Мы надеемся, что, сохраняя объекты, мы можем избавиться от наших отношений на уровне строк и сохранить их на объекте (как ООП). Проблема в том, что мы не смогли найти какие-либо связанные с производительностью тесты (по крайней мере, последние) этих ODB, работающих и используемых на Android.
У кого-нибудь есть опыт работы с OODB на 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
Эти данные будут часто меняться. Это также собирается стать довольно огромным, поскольку нет никаких сомнений, МНОГИЕ люди ездят вниз по NJ Pike в любой момент времени.
Имея эти данные, мы должны быть в состоянии сделать снимок по требованию любого, кто ездит на щуке. Мы также должны быть в состоянии сделать снимок всех мужчин, которые едут, или всех женщин в магистрали. Мы также должны иметь возможность искать по возрасту, полу, марке, модели и т. Д.
А теперь представьте, что нам нужно выяснить, на какую полосу платных дорог должна проехать каждая машина, исходя из количества людей в автомобиле, идеального количества пассажиров, количества автомобилей в очереди и идеального количества автомобилей, которые должны стоять в очереди.,
Это очень простой пример, хотя и довольно представительный для нашей проблемы.
- Конец Править
Заранее спасибо!
4 ответа
Вот некоторые наблюдения, хотя я подозреваю, что это не поможет вам напрямую.
Я думаю, что основные вопросы таковы: собираетесь ли вы обнаруживать свои сложные отношения с помощью логики времени выполнения приложения по мере того, как события генерируют или изменяют данные, или вам придется просто сбросить данные в хранилище, а затем обнаружить непредвиденные отношения с помощью запроса?
Если ваша бизнес-логика будет заполнять модель, то вы можете легко создавать основанные на модели представления ваших различных фрагментов модели данных, например, коллекций, которые знают все автомобили с водителями мужского и женского пола. В этом случае, по сути, ваши отношения полустатичны и редко изменяются (в то время как значения данных на другом конце этих отношений, вероятно, сильно меняются). Если это так, то зачем пытаться хранить данные в технологии базы данных, которая заставляет вас постоянно пересчитывать отношения (JOIN). Это просто пустая трата процессора, и поэтому вы увидите низкую производительность, поскольку модель становится сложной. Так что, как только вы ответите на эти вопросы, станет ясно, является ли ODB или RDB лучшим выбором.
Теперь возникает вопрос, что будет работать на Android и обрабатывать огромные данные? Здесь я думаю, что не могу помочь. Я работаю в Versant, у которого есть ( db4o и Versant) ODB. Теперь db4o будет работать на Android, но на самом деле это правильный выбор для огромных данных... Нет. Нет, если у вас нет очень изолированных данных, которые могут быть в отдельных базах данных и доступны только по отдельности, и для меня это не звучит как ваша ситуация. Другая наша база данных, Versant, предназначена для обработки больших данных практически в режиме реального времени, но только клиент на 100% Java, сервер написан на C, поэтому он не будет работать на Android.
Я думаю, вам нужно будет провести некоторое исследование, чтобы выяснить, у кого есть ODB, который может обрабатывать огромные данные на Android.
Бест, Роберт
Вы не особо много говорите о своих потребностях в доступе к данным или о загрузке данных.
Если у вас есть 3M основных строк, а затем куча меньших конечных таблиц, то вы можете просто преуспеть, кэшируя все конечные таблицы в ОЗУ и "соединяя" их вручную. Многие системы имеют очень маленькие конечные таблицы (особенно по сравнению с основными данными), поэтому их загрузка в ОЗУ, а затем просто поиск их при загрузке строки может быть большой победой.
Очевидно, что вы не делаете этого с основными отношениями родитель-потомок, но если вы можете исключить листовые объединения, тогда чтение становится единым соединением между родителем и потомком, а не полдюжиной к родительским, дочерним и листовым таблицам.,
Даже если это не сработает для всех конечных таблиц, если оно работает для большинства, этого вполне может быть достаточно, чтобы перебить вас.
Говоря о db4o: мы запускаем все наши регрессионные тесты на Android, потому что думаем, что это станет очень важной платформой для db4o.
db4o работает очень хорошо для порядка 3 миллионов объектов.
Мы проводим тестирование производительности с другими базами данных на http://www.polepos.org/ и вскоре мы выпустим новую версию теста, в котором мы запустим сложную настройку, в том числе для SqlLite. Портирование эталона на Android также является соображением.
Если объединения снижают производительность и у вас очень разнородные данные, db4o может работать лучше, чем реляционная база данных.
Ваше приложение звучит интересно. Если вам нужна помощь в оценке db4o, просто напишите мне.
Джейсон: для достижения любого члена db4o вы должны использовать этот шаблон: firstname @ db4o.com Best!