Application Developer Days 2: Отчет Кудрявцева В.Б/NoSQL-практикум — CouchDB

Ссылки сюда (2) →

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

Задача

Если коротко, система выглядит так:

• Имеются разнообразные счетчики потребление электроэнергии, способные замерять некоторые параметры (количество потребленной энергии, мощность, силу тока и т. д.). Счетчики разные, протоколы общения тоже разные.
• Все они подключены тем или иным проводным протоколом к УСПД — программируемому (на Java2ME) устройству, которое способно накапливать данные.
• УСПД время от времени (стандартно — раз в день, но зависит от разных обстоятельств, включая наличие связи) передает данные на центральный сервер. Передача происходит по сетям сотовой связи, Data over GSM или GPRS.

Особенности:

• Много записей, редкие чтение
• Разные, нестабильные каналы связи
• Многократное дублирование данных (в самих счетчиках, в УСПД, на сервере)
• Постоянная модернизация (новые счетчики, новые параметры измерений и т. д.)

Система

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

• База данных MySQL
• Сервер приложений (python)
• Веб-интерфейс пользователя (HTML+CSS+JavaScript)

Второй вариант сделали на CouchDB, которая сразу совмещает все 3 функции:

• NoSQL хранилище (документ-ориентированная)
• JavaScript сервер приложений (логика хранится в самой БД, в специальных документах)
• Веб-сервер

Что это дало по утверждению автора?

• Высокую скорость разработки:
  • Один язык для всего — JavaScript
  • Документ-ориентированная схема хранения намного легче изменяется (нет всех этих alter table)
  • Масштабируемость из коробки
• Легкость развертывания (нужно развернуть только CouchDB и положить туда документы с логикой)

CouchDB

CouchDB написан на Erlang, к ней, кстати, можно писать плагины на этом языке. Как работает же CouchDB?

• Язык общения — REST
• Формат общения — JSON. Поле добавляется в БД просто добавлением поля к документу
• Есть мастер-мастер репликация
• Есть транзакции, она же пакетная обработка (можно отправить одним запросом сразу несколько документов, они будут обработаны пакетом)
• MapReduce
• Append-only. Все пишется в один файл.
  • Автоматическая историчность
  • Но за все надо платить — БД занимает больше места

Резюме

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

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