Аннотация
- Докладчик
- Артур Орлов
Опыт создания системы учета электроэнергии с примением 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. Все пишется в один файл.
- Автоматическая историчность
- Но за все надо платить — БД занимает больше места
Резюме
Слушать было очень интересно — удачный выбор специфического инструмента это всегда ценно. Задумался о том, что в маленьких домашних проектах нужно расширять кругозор, пытаться искать что-то специальное, что поможет решить ту или иную задачу быстрее и эффективнее, чем написание программы на языке общего назначение/стандартной архитектуры.
А вот для нашей корпоративной практики я боюсь этот опыт мало применим — наши системы обычно решают слишком большое количество разнообразных задач, чтобы отказываться от инструментов общего назначения, а интеграция со специальными инструментами для решения особых задач почти всегда стоит дороже, чем написания пускай даже менее эффективного решения без изменения парадигмы.
Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.
