Тестирование кластеризации MongoDB с Morphia - PullRequest
Новая
       8

Тестирование кластеризации MongoDB с Morphia

4 голосов
/ 17 декабря 2010

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

Я использовал Morphia (слой отображения POJO поверх драйверов Java Mongo ) для сохранения 10000 простых случайных документов в одной коллекции. Я аннотировал свой 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 тыс. Записей, но в базе данных только <10 тыс. </li>
  • Java сообщает, что зафиксировано <10k, а база данных сообщает либо об одном значении, либо даже меньше </li>
  • Все работает нормально

В одном случае узлы, которые были восстановлены, не могли фактически догнать узел PRIMARY и должны были быть запущены с нуля с удаленной базой данных. И это несмотря на увеличение параметра opfile до 2 гигабайт, что, я думаю, было бы достаточно для воспроизведения 10000 строк очень простых данных.

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

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

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

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

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

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

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

1 Ответ

2 голосов
/ 17 декабря 2010

MongoDB определенно используется "в прайм-тайм" во многих местах прямо сейчас. Поэтому стоит взглянуть на то, что еще может здесь происходить.

Итак, пара начальных вопросов здесь:

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

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

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

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

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

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

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

...