Хранение нереляционных данных в Azure

Мы создаем платформу для благотворительности и хотим регистрировать все происходящие действия. Например

  • Джон Доу (ссылка) пожертвовал 20 долларов на проект «Дети в беде» (ссылка)
  • Джон Доу (ссылка) присоединился к команде Architects (ссылка)
  • Джон Доу (ссылка) подружился с Дэйном Доу (ссылка)
  • Проект Дети (ссылка) выложил новое фото (фото)...

Так что это похоже на стену Facebook. Вопрос в том, как сохранить это в Azure? В настоящее время мы используем Azure SQL и сохраняем определенные поля в JSON, а затем на основе другого поля мы отображаем действие. Но мы не можем искать в этих данных и т. д., что очень плохо.

Я проверил службы таблиц, которые идеально подходит для этого. Единственная проблема - производительность и заказ. Многие говорили, что поиск по неиндексированному полю очень медленный + нам нужен порядок (я не знаю, какой здесь порядок по умолчанию, вероятно, ASC - где-то нам нужен DESC, где-то ASC).

Другие предлагали использовать Lucene.net, просто чтобы где-то хранить данные и чтобы lucene индексировала данные. Тогда мы можем легко найти и заказать. Единственная проблема заключается в обновлении индекса (когда мы что-то делаем на платформе, это должно отображаться немедленно, поэтому мы не можем перестроить индекс за 1 час или около того). Я знаю, что мы, вероятно, можем обновить индекс и просто переиндексировать записи, которые моложе какой-то даты. Это может сработать.

Третий вариант — установка базы данных nosql, такой как mongodb. Но читая онлайн, никто не подтвердил, работает ли это. Но я заметил, что в магазине Azure есть mongodb.

Что ты предлагаешь? Была ли у кого-нибудь подобная проблема и как вы ее решили?


person FrEaKmAn    schedule 22.11.2012    source источник


Ответы (3)


lucene.net — хорошее решение, оно может предоставить вам поиск почти в реальном времени. пожалуйста, прочитайте книгу под названием "Lucene в действии". хотя это предназначено для версии java, но большинство вещей в версии .net такие же. посмотрите, может ли это помочь вам.

person Mandy    schedule 22.11.2012

На самом деле индексы таблиц реляционной базы данных сами являются подтаблицами. Имея это в виду, поддержка индексов в хранилище таблиц Azure на самом деле зависит от наличия дополнительных таблиц или строк, которые служат индексами. То, от чего вы отказываетесь с парадигмой NoSQL, на самом деле является ACID-свойствами реляционных баз данных, и это то, о чем вам нужно будет позаботиться в своем приложении. (Как это сделать, выходит за рамки этого ответа и зависит от ваших требований).

Отвечая на ваш вопрос, вам нужно сохранить обе ссылки, чтобы обеспечить эффективные запросы. Например, ваша ссылка «человек-друг» должна иметь обе ассоциации; они могут находиться в одной или в двух отдельных таблицах. Что-то вроде, Джон Доу — Дейн Доу, друг и Дана Доу — Джон Доу, друг. Тогда у вас будет индекс и для Джона, и для Даны, и вы сможете получить всех их друзей с помощью эффективного запроса.

Если у вас действительно нет потребностей в масштабируемости, я бы рекомендовал использовать маршрут Azure SQL вместо маршрута хранилища таблиц. Свойства ACID трудно реализовать на прикладном уровне, и именно ACID делает реляционную базу данных такой надежной.

person hocho    schedule 22.11.2012

вы рассматривали использование баз данных графов, таких как Neo4J?

вот видео реального рабочего приложения neo4j в Azure: http://blog.tatham.oddie.com.au/2012/06/18/new-talks-neo4j-in-a-net-мир-и-вы-в-производстве-сейчас-что/

person JuneT    schedule 23.11.2012