Вам необходимо хранить данные на Android-устройстве, думая о выходе OODB

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

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

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

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

- Изменить

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

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

автомобиль

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 в любой момент времени.

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

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

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

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

Спасибо заранее!

Ответ 1

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

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

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

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

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

Бест, -Роберт

Ответ 2

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

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

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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