Тестирование кластеризации MongoDB с помощью Morphia

Я пробовал MongoDB в конфигурации с набором реплик, чтобы посмотреть, как она масштабируется/работает/справляется.

Я использовал Morphia (слой сопоставления POJO поверх Java-драйверы Mongo) для сохранения 10 000 простых случайных документов в одной коллекции. Я аннотировал свой POJO (MyData во фрагменте ниже) аннотацией @Entity(concern="REPLICAS_SAFE") в надежде, что данные, отправленные в базу данных, будут безопасно сохранены.

Мой POJO состоял из поля ObjectId (тип первичного ключа Mongo), String случайных символов случайной длины (максимум 20 символов) и long, сгенерированного с использованием Random.nextLong().

Мой код следующий:

for (int i=0;i<10000;i++) {
    final MyData data = new MyData();

    boolean written = false;
    do {
        try {
        ds.save(data); //ds is of type DataStore
        written=true;
        } catch (Exception e) {
            continue;
        }
    }
    while (!written);
}

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

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

Фактический результат после нескольких подходов был одним из:

  • Java сообщает, что он зафиксировал 10 000 записей, но в базе данных было только ‹10 000
  • Java сообщает, что она зафиксировала ‹10k, а база данных сообщает либо о том же значении, либо даже меньше
  • Все работает нормально

В одном случае узлы, которые были восстановлены, не смогли фактически догнать ОСНОВНОЙ узел, и их пришлось запускать с нуля с удаленной базой данных. И это несмотря на увеличение параметра opfile до 2 гигабайт, которых, как мне казалось, будет достаточно для воспроизведения 10 000 строк очень простых данных.

Другие вещи, которые вы должны знать:

  1. Все это работает на одном оборудовании (2 гигабайта Pentium D!), кластер работает на двух 32-битных экземплярах Ubuntu Server VirtualBox с 128 мегабайтами оперативной памяти каждый и Java-клиентом, работающим внутри хоста Windows XP. На каждой виртуальной машине выполнялось два mongod процесса, а на также одна виртуальная машина.
  2. Часы на двух виртуализированных машинах были отключены на несколько секунд (мне нужно установить гостевые дополнения VirtualBox, чтобы исправить это), но не на большую величину — 10gen говорит, что время не должно быть проблемой для кластеризации, но я подумал, что д упомянуть об этом.

Я знаю об ограничении в 2 гигабайта с Mongo на 32-разрядной машине, о том факте, что у других людей исчезали записи, и я знаю, что машина, на которой я провожу эти тесты, точно не входит в число 500 лучших (именно поэтому данные, которые я выбрал для persist было мало), но когда мои тесты работали, они работали очень хорошо.

Являются ли проблемы, которые у меня были, доказательством того, что Mongo еще не готов к работе в прайм-тайм, или я делаю что-то изначально неправильное?

Я использую 1.6.5.

Любое понимание, подсказки, советы, указатели, объяснения или критика очень ценятся!

ps: я не троллю - мне очень нравится идея NoSQL для тех типов данных, для которых он хорош, поэтому я действительно хочу, чтобы он работал, но пока мне не везет!


mongodb cluster-computing morphia
person Rich    schedule 17.12.2010    source источник

Ответы (1)


arrow_upward
2
arrow_downward

MongoDB определенно используется «в прайм-тайм» во многих местах прямо сейчас. Так что стоит взглянуть на то, что еще может происходить здесь.

Итак, пара стартовых вопросов:

  1. Как работает «новые MyData()»? Возможно ли, что вы забиваете существующие идентификаторы?
  2. Ваши реплики устанавливаются в течение всего процесса? Вы просто «продолжаете» ошибку, поэтому я не совсем уверен, как обрабатываются ошибки. Правильно ли Morphia всплывает ошибки?

Я очень ценю, что вы прошли и написали своего рода «тестовый пример», но я думаю, что вам нужно копнуть на один шаг глубже в этом случае. Не могли бы вы попробовать следующие две вещи?

  1. Установите _id на MyData на i. Таким образом, вы сможете увидеть, где в процессе вы умираете.
  2. Делайте console.write или эквивалент каждый раз, когда вы получаете сообщение об ошибке. Посмотрите, не можете ли вы понять, куда на самом деле ушли данные.
  3. По той же мере делайте console.write при каждом успешном сохранении.

Если вы выполните эти шаги, вы получите журнал того, что происходит, и вы сможете увидеть, что сохранено, а что нет, и сравнить это с данными в БД.

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

Либо 1. Morphia неправильно сообщает об ошибках (неправильно обрабатывается). 2. Вы обнаруживаете реальную проблему с наборами реплик.

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

person Gates VP    schedule 17.12.2010
comment
спасибо за ваш ответ и извините, что не ответили раньше, болезнь, а затем праздники мешают - я полностью намерен следить за этим в новом году! - person Rich; 23.12.2010
comment
Эй, я знаю о праздниках. Если этот тест относительно прост, вы также можете попробовать опубликовать пару сущностей, которые позволят другим повторить то, что вы делаете. Скорее всего, должно быть два сценария: один сценарий для отображения процесса запуска и другой сценарий для отображения вашего обновления/тестового примера. - person Gates VP; 27.12.2010