couchdb - JSON производительность в приложении Messenger

Question

У меня есть веб-приложение для обмена мгновенными сообщениями, написанное на PHP. Недавно я перешел на couchdb из mysql, и я думаю, что в целом это хорошая идея, пока она работает отлично. Мне не нужны представления и т. Д. Обычно я выбираю документ по идентификатору.

Однако у меня есть некоторые сомнения по поводу производительности. Разговор между двумя пользователями хранится в одном документе. Например, между A и B, у меня есть документ, между C и B, у меня есть другой документ и т. Д.

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

Я прав? Как лучше хранить такие большие массивы в базах данных no-sql?

Answer 1

Я бы смоделировал это по-другому;Используйте документ для каждой сказанной вещи.{"from": "foo", "to": "bar", "text": "hey there"}.Таким образом, вы только когда-либо создаете новые документы, и каждый документ остается очень маленьким.

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

Вы захотите использоватьвремя сервера для обеспечения правильного порядка, поэтому я рекомендую вам обновить через обработчик обновлений (http://wiki.apache.org/couchdb/Document_Update_Handlers) и добавить туда отметку времени.

Answer 2

Обходной путь - иногда объединять старые сообщения в вложения CouchDB .Они не будут видны при запросе по идентификатору документа.

Например, документ беседы:

{ "_id": "alice_bob"
, "_rev": "123-abcdef"
, "messages":
  [ "alice: Hi, Bob!"
  , "alice: Are you there?"
  , "bob: Yes, what's up?"
  , // ... etc.
  , "bob: Thanks!"
  ]
}

Например, если длина беседы превышает 200 сообщений, разделите еев два массива:

• 150 самых старых сообщений ("alice: Hi, Bob", and the next 149)
• 50 последних сообщений: (49 сообщений, до "bob: Thanks!" включительно)

Архивировать старые сообщения во вложении, возможно, с отметкой времени.

{ "_id": "alice_bob"
, "_rev": "123-abcdef"
, "_attachments":
  { "2011-09-19T17:29:17.293Z.json":
    { "content_type": "application/json"
    , "data": /* 150 message JSON string goes here */
    }
  }
, "messages": [ /* latest 50 messages go here */ ]
}

При получении /db/alice_bob вы не получите данные вложения, однако вы можетеизвлекать и даже удалять вложения непосредственно с этого URL.

/db/alice_bob/2011-09-19T17:29:17.293Z.json

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