Аннотация
- Докладчик
- Артур Орлов
Опыт создания системы учета электроэнергии с примением CouchDB.
- Вводная часть.
- Немного об истории разработки и специфика задачи. Основные требования к системе учета.
- Архитектура системы учета и место CouchDB в ней.
- Очень кратко о возможностях CouchDB.
- Основная часть.
- CouchDB как база данных для системы учета; задачи, решаемые ею.
- Проектирование БД на основе CouchDB.
- Расширение возможностей: создание модулей расширения для CouchDB на Erlang.
- Итоги: «за» и «против», сравнение с аналогичными решениями на основе SQL-БД.
- Практические рекоммендации разработчикам, основанные на опыте эксплуатации внедренной системы учета электроэнергии на базовых станциях в одном из филиалов оператора сотовой связи «МТС-Узбекистан».
Видео
- Скачать
http://ftp.linux.kiev.ua/pub/conference/peers/addconf/2011/1b9-nosql-practice-couchdb-orlov.avs.avi
Для этого доклада нужен подкаст (аудиозапись)?
Примечания и отзывы
Тоже очень интересный доклад. Перед выступающим стояла задача автоматизировать сбор данных с электро-счетчиков через GPRS. Прототип они писали на Python + Postgres, но в итоге решение получилось очень элегантное.
CouchDB по сути сама может выступать как сервер приложений с выполнением JavaScript-кода. Например, может отдавать HTML. Соответственно если логики обработки данных мало, то можно обойтись без сервера приложений вообще. Вроде бы это тот же PL/SQL, только в профиль. Но JS как язык все-таки поинтереснее. Я его недолюбливаю, но это связано с поддержкой браузерами, в БД же все должно быть стабильнее.
Итого, отрекламировал CouchDB докладчик отлично. Осталось ощущение крутоты технологии. Тоже советую доклад в записи посмотреть.
Докладчик — с одной стороны, Капитан Очевидность, видимо не так давно открывший для себя базы данных. Создавайте индексы, смотрите планы запросов. O_o
Но зато рассказал про реализацию системы учёта показаний электросчётчиков на CouchDB — ещё одной NoSQL-базе.
CouchDB — это не просто NoSQL-база данных, написанная на Erlang’е, она также содержит внутри себя сервер приложений, который может выполнять javascript, и благодаря этому оно простое и быстрое. Интерфейс к CouchDB — HTTP-запросы (методы GET, PUT, POST, DELETE). Правда, это вам не Mongo и масштабирование — не её сильная сторона — всё масштабирование сводится к мастер-мастер репликации. Но они и не масштабировались, по оценкам им надолго текущей архитектуры хватит.
Кратенько: там есть документы (просто хэш/словарь, какой термин кто больше любит), и дизайн-документы, которые представляют из себя какой-то код, который может, например, что-то агрегировать с помощью map-reduce (получится как бы «view»). Хранит всю историю изменений, вся БД в одном файле, который только растёт вперёд и его нужно время от времени перепаковывать — привет, ACID и MVCC (да, таки оно и есть), PostgreSQL и VACUUM. Есть индексы, правда, их заполнение происходит по требованию и поэтому если накапливается много обновлений — первый запрос будет подтормаживать. Это решается, по-видимому, просто регулярным дёрганьем view по расписанию. Ещё есть простой интерфейс типа «запросить все изменения с момента заданного sequence number», что позволяет легко делать всякие онлайн-обновляемые твиттеры-странички.
Прикольная штука, короче.
- NoSQL-практикум: Промышленная автоматизированая измерительная система на CouchDB (Артур Орлов, ADD-2011)
Система учета электроэнергии собирает данных с измерительных приборов (в простонародье «счетчики»). Изначально система была вн РСУБД + python. Потом решили использовать CouchDB (почему? по-моему, их заели репликации, а тут значительно проще) В общем, рассказывал, что такое и как делать для него приложения. Очень симпатично: написана на Erlang, включает web-сервер, логика пишется на JavaScript и хранится особыми документами в БД, работа через REST API. Захотелось попробовать.
Артур Орлов, независимый разработчик, кажется, из Узбекистана, рассказывал про систему, собирающую данные со счетчиков электроэнергии в домах и промышленных предприятиях.
Задача
Если коротко, система выглядит так:
- Имеются разнообразные счетчики потребление электроэнергии, способные замерять некоторые параметры (количество потребленной энергии, мощность, силу тока и т. д.). Счетчики разные, протоколы общения тоже разные.
- Все они подключены тем или иным проводным протоколом к УСПД — программируемому (на 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. Все пишется в один файл.
- Автоматическая историчность
- Но за все надо платить — БД занимает больше места
Резюме
Слушать было очень интересно — удачный выбор специфического инструмента это всегда ценно. Задумался о том, что в маленьких домашних проектах нужно расширять кругозор, пытаться искать что-то специальное, что поможет решить ту или иную задачу быстрее и эффективнее, чем написание программы на языке общего назначение/стандартной архитектуры.
А вот для нашей корпоративной практики я боюсь этот опыт мало применим — наши системы обычно решают слишком большое количество разнообразных задач, чтобы отказываться от инструментов общего назначения, а интеграция со специальными инструментами для решения особых задач почти всегда стоит дороже, чем написания пускай даже менее эффективного решения без изменения парадигмы.
