Умный или нет: сохранить сериализованные данные (dotnet-protobuf, protobuf-net, json) в реляционной БД в CF - PullRequest
7 голосов
/ 14 мая 2010

Я начал читать некоторые посты, связанные с буферами протокола. Метод сериализации кажется очень подходящим для передачи данных на веб-серверы и с них. Кто-нибудь рассматривал возможность использования такого метода для сохранения и извлечения данных на самом мобильном устройстве? (т. е. замена традиционного уровня базы данных / orm). В настоящее время мы используем пользовательскую форму, основанную на отражении. Мы хотим уйти от использования отражения на мобильных устройствах. И, поскольку мы все равно должны отправлять / получать сериализованные данные, это выглядит как хорошая подгонка.

  • Где будут храниться данные?
  • Как будут запрашиваться данные?

Имеет ли смысл хранить данные в традиционной базе данных (SqlCE или SqlLite) с несколькими «доступными для поиска» столбцами, а затем одним столбцом для сериализованных данных?

Мысли? Я здесь на конечности?

Обновление: эта же "теория" может работать и для других типов сериализованных данных ... JSON, например. Мне не удалось найти вариант NoSQL для хранения и запроса сериализованных данных в Compact Framework. Я бы тоже заинтересовался этим вариантом, если бы кто-нибудь знал об этом.

Комментарий к объектным базам данных Я пробовал оба db4o и Perst. Работать с db4o было просто замечательно. Я использовал его в «реальной жизни», а производительность, удобство и простота обслуживания были превосходны. Их лицензионные сборы в нашей ситуации были тем, что я бы посчитал возмутительным. Perst был на шаг ниже db4o, но с ним было приятно работать. Это «просто работало» и было быстрым (хотя и не таким приятным для запроса). Их лицензирование было очень доступным, но что-то в их лицензировании было неприемлемо для (большой, известной) корпорации, с которой я заключаю контракт. Это приводит меня туда, где я сейчас нахожусь ...

Ответы [ 3 ]

4 голосов
/ 21 мая 2010

Ну, так как никто больше не пытался ответить на этот вопрос, я выскажу свое мнение. Имейте в виду, что я никогда не использовал protobuf (именно поэтому я еще не ответил), так что все это просто основано на моем свободном понимании вещей и как, если бы у меня была эта проблема, чтобы решить, я продолжил бы.

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

Из-за должной осмотрительности я бы, по крайней мере, добавил профильные вставки в базу данных SQLCE. Почему SQLCE вместо SQlLite или какой-то другой RDMS? Ну, потому что SQLCE поддерживает TableDirect, который я огромный фанат. В любой момент, когда вы можете получить доступ к данным, не используя медленный процессор запросов, вы далеко впереди.

Итак, я бы создал таблицу, дал бы ей пару небольших столбцов для поиска, по которым я мог бы искать, затем столбец изображения, содержащий некоторый большой двоичный двоичный объект (сам по себе двоичный объект не подходит для теста, но он должен быть достаточно близким по размеру к тому, что вы ожидаете в производстве). Затем я бы добавил индексы для каждого столбца поиска.

Я бы заполнил таблицу несколькими тысячами записей, а затем профилировал бы скорость, с которой я мог бы искать нужный ключ (я знаю, что это быстро), и, что более важно, скорость, с которой я могу повторно увлажнять свои объекты.

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

0 голосов
/ 27 октября 2013

Это важный вопрос, если вы посмотрите на MariaDB 10, мы представили динамические столбцы, которые хранят базу данных структурированных объектов в BLOB-объекте https://mariadb.com/kb/en/dynamic-columns/ Преобразование клиентской стороны из BLOB-объекта во все, что может быть упрощено клиентом потому что мы встраиваем API в драйвер C. Я думаю, что мы включаем только экспорт json, но с небольшими усилиями это, вероятно, может быть расширено до серийного, десериализованного protobuf.

0 голосов
/ 21 июня 2010

Я не видел этого в то время (извините, но я не вижу всех вопросов, и хотя я наблюдаю за тегом protobuf-net, я не сохраняю такую ​​же бдительность на protocol-buffers. Очень интересный Вопрос: С точки зрения сравнения с базой данных document (а не реляционной), я думаю, что этот тип подхода имеет большой потенциал. Кажется, little излишне смотрит на реляционную, если вы просто отбрасывать капли, но это должно сработать, по крайней мере. Я, конечно, часто использовал подобные настройки для загрузки данных в автономные приложения - не , в частности для мобильных устройств, но применимы те же понятия.

В частности, этот тип документа-ориентированного подхода полезен, когда вы хотите повторно гидратировать «систему»; то есть состояние в полном объеме. Они не так просты / гибки для запроса ad-hoc, как реляционная база данных. Конечно, одним из вариантов является повторная гидратация, и они выполняют запрос в памяти (например, в C # запрос LINQ-to-Objects для повторно гидратированных данных будет почти неотличим от запроса LINQ-to-SQL для данных в реляционной базе данных. ).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...