Нужно хранить данные LOTS на устройстве 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 в любой момент времени.

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

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

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

– Конец Редактировать

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

Solutions Collecting From Web of "Нужно хранить данные LOTS на устройстве Android, думая о выходе OODB"

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

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

Если ваша бизнес-логика заполнит модель, вы можете легко создавать представления, основанные на модели, на разных фрагментах модели данных, например, коллекции, которые знают все автомобили с драйверами для мужчин и женщин. В этом случае, в основном, ваши отношения очень редко меняются (хотя значения данных на другом конце этих отношений, вероятно, сильно меняются). Если это так, то зачем пытаться хранить данные в технологии базы данных, что вынуждает вас постоянно пересчитывать отношения (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 Лучшее!