Оптимизация / кэширование событий с возможностью поиска - PullRequest
2 голосов
/ 07 декабря 2011

В моем приложении Ruby on Rails я создаю календарь с плагином Fullcalendar JQuery для представлений и использую гем Icecube для расчета повторяемости событий.Я также использую Thinking Sphinx для поиска.

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

Я хотел бы кэшировать вычисление происходящих событий, и подумал, что могу сериализовать массив событий в пределахстолбец базы данных событий.

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

Я не уверен, как или дажеЯ могу заставить Thinking Sphinx искать сериализованный массив, хотя.Возможно ли это, и как бы я определил это в моих моделях блока define_index?

Есть ли более эффективный способ кэширования / поиска времени возникновения события?Или есть какие-то другие решения, которые люди использовали для решения аналогичной проблемы поиска объектов Arrays of Time?

Ответы [ 2 ]

0 голосов
/ 04 января 2012

Хитрость в том, чтобы Sphinx мог осуществлять поиск в кэшированных экземплярах, заключался в использовании списка меток времени через запятую. Это позволяет вам определять индекс типа: multi так:

define_index do
  indexes :description
  indexes :name, :sortable => true
  indexes :location, :sortable => true
  has :calendar_id
  has :client_id
  has :end_at
  has :start_at
  has "calendar_events.occurrence_cache", :as => :occurrence_cache, :type => :multi 
  set_property :delta => true
end

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

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

sphinx_scope(:ts_by_occurrence_at) do |occurrence_at_or_range|
  {:with => {:occurrence_cache => occurrence_at_or_range}}
end
0 голосов
/ 07 декабря 2011

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

Если вы будете придерживаться строгой методологии «одно событие - одна запись», вы сможете значительно оптимизировать свой поиск. Простой подход - ввести столбец календарного месяца, который можно проиндексировать, и использовать его в области для извлечения событий:

@events = @user.events.where(:yearmonth => yearmonth)

Столбец yearmonth содержит YYYYMM отформатированные значения. При необходимости вы также можете индексировать по дате или неделе.

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

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

Если вам нужна производительность и масштабируемость в этот момент, на самом деле не так сложно развернуть свой собственный постоянный серверный процесс, который использует стандартный протокол, такой как Memcached, и использовать его в качестве своего рода хранилища данных NoSQL.

...