Дизайн документов CouchDB для Facebook Insights

Я начинаю работать над CouchDB для сбора аналитической информации из Facebook Insights и других источников. Я не уверен в правильности дизайна документа и хотел бы, чтобы более опытные пользователи CouchDB увидели его и предупредили меня, если я собираюсь совершить какую-либо большую ошибку.

{
"_id": "0b69a33807d4cb63680dbebc16000af5",
"_rev": "1-7c9916592c377e32cf83acf746a8647c",
//array of metrics, one element per facebook page, around 10 pages per document**
"metrics": [        
    {
        "sourceId": "210627525692699", //facebook page ID
        "source": "facebook",
        "values": {
           "page_likes": 53
           //many more other metrics, around 100
       }
   },
   {
       "sourceId": "354413697924499", // //facebook page ID
       "source": "facebook",
       "values": {
           "page_wall_posts_source_unique": {other: 0, composer: 1},
           "page_likes": 12
           //many more other metrics, around 100
       }
   }
],
"timestamp": [
   2012,
   10,
   15,
   10,
   0,
   0
],
"customerId": "71ff942f-9283-4916-ab84-4927bce09117"
}

Ожидаемое количество документов: +10 000 каждый час, +240 000 ежедневно.

Ожидаемые запросы к документам:

  • сумма значений на клиента, на sourceId, на метрику в заданный период времени
  • специализированные представления для более сложных показателей

Вопросов:

  • Чтобы получить аналитику для некоторых сложных метрик (например, page_wall_posts_source_unique), нам нужно будет создать специализированные представления, возможно, многие из них, следует ли ожидать проблем со временем обновления представления?
  • Правильно ли использовать массив для метки времени или лучше использовать длинный?
  • Должен ли я использовать один проектный документ или помещать каждое представление в новое?

couchdb facebook-insights
person Dmitriy Fot    schedule 06.12.2012    source источник
comment
Это отличный вопрос. Я недостаточно эксперт, чтобы дать окончательный ответ, но я выскажу свое мнение. Использование массива для метки времени - это нормально, но вам будет проще использовать long. (Запросы с массивами работают, но правильное форматирование URL-адреса немного болезненно.) Поскольку представления обновляются при обновлении их проектного документа, вы можете захотеть сохранить представления в отдельных проектных документах.   -  person lambmj    schedule 06.12.2012

Ответы (2)


arrow_upward
0
arrow_downward

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

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

Кроме того, CouchDb не предназначен для миллионов небольших документов. Предпочитают манипулировать средним количеством документов среднего размера. Но миллионы небольших документов не идеальны для систем просмотра CouchDb.

Поэтому я советую вам выбрать свои основные цели и взглянуть на другие решения NoSQL, потому что в мире NoSQL нет единого решения для всех целей, вместо этого есть собственное решение для выбранных целей, не как в SQL, когда вы используете один на все. На первый взгляд, я думаю, что MongoDB должен соответствовать вашим целям.

Но, в любом случае, отвечая на ваш вопрос: 1) Думаю, что да, но это зависит от того, сколько документов будет пересчитано 2) Я предпочитаю использовать длинное значение, потому что это когда у вас есть одно значение, вы можете запросить его, бит, если у вас будет массив другое значение, у вас будут проблемы с этим. А также использование длинных меток, таких как временные метки, - обычная практика. 3) В этом нет ничего сложного. Вы можете поступать так, как хотите.

person Ph0en1x    schedule 08.12.2012

arrow_upward
0
arrow_downward

Спасибо за ответы, ребята.

Ph0en1x, я частично согласен с вами, CouchDB не был очевидным выбором, но я еще менее уверен в других вариантах, пока что буду придерживаться CouchDB.

В любом случае, вот ответы, которые я собрал из нескольких источников:

1) очевидно, это зависит от количества документов. но с небольшими документами вероятность возрастает.

2) оба подхода будут работать, отметка времени немного более универсальна.

3) Чем больше просмотров в одном документе, тем выше вероятность их частой переиндексации. Поэтому я стараюсь свести количество просмотров в одном документе к минимуму.

person Dmitriy Fot    schedule 09.12.2012