Задача. n клиентов циклически отправляют данные о своем состоянии на сервер через http соединение POST запросом. Сервер в свою очередь сохраняет эти данные и по первому запросу пользователя отображает в виде графика. Требуется выяснить основанную на какой модели базу данных лучше использовать для хранения информации. Странный вопрос? Я кажется перегрелся в машине по дороге домой…

Небольшое уточнение. Модель определяет в базе как данные будут хранится и как использоваться. Какие модели данных есть вы можете прочесть тут http://www.unixspace.com/context/databases.html. Я только выделю реляционную и нереляционную. И теперь, скорее всего, у вас возникнет вопрос. Пробую угадать и сразу пишу ответ. Отвлекитесь от всего что нам говорили в университете о полезности реляционных баз данных. Борьба с избыточностью, замечательные SQL запросы… круто и главное что всегда рядом. Обратим внимание на слово – нереляционность.

Берем данные, полностью денормализируем и сохраняем. Ужас? Я пока точно не знаю, но давайте внимательно посмотрим что у нас происходит в web приложении. Несколько вопросов:

1. Какая операция чаще происходит? запись или чтение?
2. Уникальные ли данные выводятся каждый раз в нашем приложении на разных страницах?

Мои ответы (ваши с удовольствием прочту в комментариях):

1. Чтение
2. Не уникальные.

Эти вопросы-ответы очень важны. Смотрим на ответ номер 2. Казалось бы данные уникальные. Но в процессе написания кода часто замечаешь обратное: они одинаковые, просто на некоторых представлениях ты их изменяешь. То есть каждый раз как ты строишь представление, ты выполняешь неприлично красивый SQL запрос, модифицируешь данные и отдаешь пользователю. А что происходит при записи? Вставка данных и все. Теперь посмотрите на ответ номер раз. Никаких замечаний?
Что предлагает нереляционных подход? Сплошная избыточность. Простая свалка документов которые идентифицируется по ключу. Надо нам 10 разных представлений? Не вопрос. Сделаем и сохраним. А при выводе информации просто возьмем требуемое и отобразим.

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

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

0. (Не)много болтологии.
1. Маленький клиент.
2. Простое серверное web приложение c использованием Spring, Hibernate. В качестве сервера DB возьму MySQL. Его очень много рядом.
3. Вторая копия веб приложения с замененным слоем работы с базой данных. В качестве сервера возьму CouchDB.
4. Нагрузочное тестирование и анализ результатов.

На этом запись номер 0 окончена. С удовольствием выслушаю ваши замечания, предложения и комментарии.

Небольшая ремарка. С азбукой русского языка у меня не все в порядке, поэтому в некоторых словах буквы будут не правильными, а знаки препинания будут шляться в не положенных им местам. Сохраняйте спокойствие :)