В последнее время термин “NoSQL” стал очень модным и популярным, активно развиваются и продвигаются всевозможные программные решения под этой вывеской. Синонимом NoSQL стали огромные объемы данных, линейная масштабируемость, кластеры, отказоустойчивость, нереляционность. Однако, мало у кого есть четкое понимание, что же такое NoSQL хранилища, как появился этот термин и какими общими характеристиками они обладают. Попробуем устранить этот пробел.
Рубрика «nosql» - 32
NoSQL базы данных: понимаем суть
2012-09-27 в 8:16, admin, рубрики: nosql, базы данных, высокая производительность, метки: nosql, базы данных, высокая производительностьГрафовая база данных Neo4j в PHP
2012-09-24 в 10:03, admin, рубрики: mongodb, neo4j, nosql, php, метки: mongodb, neo4j, nosql, PHPВ последнее время я все чаще слышу о NoSQL и о графовых базах данных в частности. Но воспользовавшись хабропоиском с удивлением обнаружил, что статей на эту тему не так и много, а по запросу «Neo4j», так вообще 4 результата, где косвенно упоминается это название в тексте статей.
Что такое Neo4j?
Neo4j — это высокопроизводительная, NoSQL база данных основанная на принципе графов. В ней нет такого понятия как таблицы со строго заданными полями, она оперирует гибкой структурой в виде нод и связей между ними.
Как я докатился до этого?
Уже более года я не использовал в своих проектах SQL, с того времени, как попробовал документо-ориентированную СУБД "MongoDB". После MySQL моей радости не было предела, как все просто и удобно можно делать в MongoDB. За год я переписал тройку CMS, использующих основные фишки Mongo c её документами, и с десяток сайтов работающих на их основе. Всё было хорошо, и я уже начал забывать, что такое писать запросы в полсотни строк на каждое действие с БД и все бы ничего пока на мою голову не свалился проект с кучей отношений, которые ну никак не укладывались в документы. Возвращаться к SQL очень не хотелось, и пару дней я потратил чисто на поиск NoSQL решения, позволяющего делать гибкие связи — на графовые СУБД. И по ряду причин мой выбор остановился на Neo4j, одна из главных причин — это то, что мой движок был написан на PHP, а для неё был написан хороший драйвер "Neo4jPHP", который охватывает почти 100% REST-интерфейса, предоставляющегося сервером Noe4j.Читать полностью »
СУБД Cache + Erlang
2012-09-15 в 11:25, admin, рубрики: cache, erlang, Erlang/OTP, nosql, Веб-разработка, СУБД, метки: cache, erlang, СУБДВ этой статье я расскажу о том, как мы подружили Cache + Erlang, и зачем нам это нужно. СУБД Cache была выбрана в качестве хранилища данных. Также мы создали и эксплуатируем MCA(Middleware for Cache Applications) — промежуточное программное обеспечение, обеспечивающее конкурентную модель взаимодействия Erlang и Cache.
Для взаимодействия Erlang и Intersystems Cache реализованы возможности:
- Обрабатывать в Cache сообщения из Erlang, транслируя Erlang tuples (внутренний древовидный формат данных Erlang) в глобалы Cache.
- Посылать из Cache сообщения процессам Erlang, транслируя глобалы Cache в Erlang tuples.
Разработанное MCA состоит из трёх основных компонент:
- Message Dispatcher(MD) — управляет обменом сообщениями в конкурентных условиях между различными Erlang-node(EN) и Cache-процессами, обеспечивает кэширование сообщений по определенным правилам. Запускается в соответствующем EN.
- C-node — обеспечивает подгрузку С/C++ библиотек и обмен сообщениями между ними, взаимодействие системы с shared-memory, EN, CallIn/CallOut (функциональностью, реализованной в Cache на языке С) и т.д. На данный момент к С-node, для веб-приложений, c использованием Cache, нами подключены библиотеки для поддержки XSLT преобразования, обработки регулярных выражений.
- Porte – шлюз обмена сообщениями (Messaging Gateway) c MD для Cache. Запускается как отдельный background job, который будем называть Porte-job(PJ).
Релиз MongoDB 2.2.0
2012-08-30 в 18:33, admin, рубрики: mongodb, mongodb 2.2, nosql, метки: mongodb 2.2, nosql Вчера состоялся долгожданный релиз NoSQL базы данных MongoDB 2.2.0.
Среди самых важных нововведений стоит отметить:
Aggregation Framework
Инструмент, оптимизирующего обработку больших массивов данных без map-reduce (больше информации на хабре)
TTL-коллекций
TTL-коллекции позволяют удалять из коллекции данные, у которых вышло время жизни, установленое с помощью специального индекса(удобно, например, для хранения логов, сессий и подобной информации). При использовании таких коллекций создается дополнительный фоновый процесс для реализации соответсвующей проверки
Читать полностью »
MongoDB и C#. Новые возможности и неочевидные проблемы
2012-07-28 в 4:32, admin, рубрики: .net, mongodb, nosql, метки: .net, c++, mongodb, nosqlВведение
В начале июля вышла очередная версия(1.5) официального драйвера MongoDB для C#. Среди нововведений стоит отметить поддержку типизированных запросов. Теперь появилась возможность использовать лямбда-функции в связке с Expression.
В этой статье я покажу примеры нового синтаксиса, который мне очень нравится(а мне вообще Expression в C# очень нравится), а также продемонстрирую примеры запросов, где, увы, Expression нам ничем не поможет и придется вернуться к привычным строкам. Также я порассуждаю, почему оно так, и будет ли когда-нибудь всё прекрасно в С# при работе с MongoDB.
Читать полностью »
Установка и использование MongoDb
2012-07-24 в 7:51, admin, рубрики: mongodb, nosql, Веб-разработка, метки: mongodbЭтот пост может быть полезен тем, кто решил попробовать Mongodb в своем проекте (использует его впервые).
Mongodb может быть хорошим решением (по сравнению с СУБД), если вам нужно хранить объекты со сложной структурой или не однотипные объекты. Также, возможности mapReduce полезны для генерации разнообразной статистики, использование mapReduce может быть гораздо удобнее использования агрегирующих функций и написания процедур в SQL.
Читать полностью »
ZooKeeper или пишем сервис распределенных блокировок
2012-07-17 в 0:36, admin, рубрики: java, nosql, zookeeper, высокая производительность, метки: zookeeperdisclaimer Так получилось, что последний месяц я разбираюсь с ZooKeeper, и у меня возникло желание систематизировать то, что я узнал, собственно пост об этом, а не о сервисе блокировок, как можно было подумать исходя из названия. Поехали!
При переходе от многопоточного программирования к программированию распределенных систем многие стандартные техники перестают работать. Одной из таких техник являются блокировки (synchronized), так как область их действия ограничена одним процессом, следовательно, они не только не работают на разных узлах распределенной системы, но так же не между разными экземплярами приложения на одной машине; получается, что нужен отдельный механизм для блокировок.
От распределенного сервиса блокировок разумно требовать:
- работоспособность в условиях моргания сети (первое правило распределенных систем —
никому не говорить о распределенных системахсеть ненадежна) - отсутствие единой точки отказа
Создать подобный сервис нам поможет ZooKeeper
В википедии написано, что ZooKeeper — распределенный сервис конфигурирования и синхронизации, не знаю как вам, но мне данное определение мало что раскрывает. Оглядываясь на свой опыт, могу дать альтернативное определение ZooKeeper, это распределенное key/value хранилище со следующими свойствами:
- пространство ключей образует дерево (иерархию подобную файловой системе)
- значения могут содержаться в любом узле иерархии, а не только в листьях (как если бы файлы одновременно были бы и каталогами), узел иерархии называется znode
- между клиентом и сервером двунаправленная связь, следовательно, клиент может подписываться как изменение конкретного значения или части иерархии
- возможно создать временную пару ключ/значение, которая существует, пока клиент её создавший подключен к кластеру
- все данные должны помещаться в память
- устойчивость к смерти некритического кол-ва узлов кластера
Big Systems / Big Data в Москве
2012-07-13 в 11:37, admin, рубрики: cassandra, nosql, Vertica, Блог компании «LifeStreet Media», метки: cassandra, nosql, VerticaВ среду вечером мы провели мероприятие в формате meetup, посвященное большим системам и большим данным: habrahabr.ru/events/836/
Если среди читателей есть те, кто там был (а это 80-100 человек из примерно 150 зарегистрировавшихся), то огромное вам спасибо. И огромное спасибо всем, кто помогал в организации и проведении.
Я не знаю, как правильно перевести слово meetup на русский. Не митапом же называть. Это не еще одна конференция, это другое. На больших конференциях, типа HighLoad, РИТ и т.д., специалисты из крупных компаний рассказывают о задачах, проблемах и решениях, которые часто находятся за пределами горизонта возможностей компаний поменьше. Это бывает очень интересно и познавательно, но по большой части малополезно с практической точки зрения. Формат meetup — он совсем другой, и больше напоминает «круглый стол». Его цель — обменяться опытом с коллегами из других компанией, с клиентами и партнерами. Обменяться «шишками» и «граблями», чтобы учиться не только на своих, но и на чужих ошибках. В Силиконовой долине такие мероприятия обычно проходят либо в офисах компаний-организаторов, либо в каких-нибудь нейтральных кафе. В Москве мы попробовали собрать людей после работы в Digital October. И это вполне получилось.
MongoDB: производительность запросов на диапазонах
2012-07-03 в 16:32, admin, рубрики: mongodb, nosqlЕсли вы путешествовали по территории индексов MongoDB, вы возможно слышали принцип: Если ваши запросы содержат сортировку, то добавте сортированное поле в конец индекса который используется в этих запросах.
Во многих случаях когда запросы содержат условия равнества как например {“name”: “Charlie”}, принцип который выше очень полезен. Но что о нем можно сказать со следующим примером:
Запрос:
db.drivers.find({"country": {"$in": ["A", "G"]}).sort({"carsOwned": 1})
Индекс:
{"country": 1, "carsOwned": 1}
Эта связка является не еффективной, хотя принцип соблюдается. Потому что тут есть ловушка в которую вас может привести этот принцип.
Ниже мы рассмотрим причины возниконвения этой ловушки и к концу статьи вы будете иметь новое правило которое будет вам помогать при индексировании.
Читать полностью »
Cassandra глазами Operations
2012-06-19 в 13:17, admin, рубрики: cassandra, nosql, Блог компании «LifeStreet Media», метки: cassandraОсновной проект компании, в которой я работаю, посвящен оптимизации показов рекламы в приложениях на фейсбуке и на мобильных устройствах. На сегодняшний день проект обслуживает до 400 миллионов уникальных посетителей в месяц, работает на тысяче с лишним виртуальных серверов. Количество серверов и обьемы данных, которые должны обрабатываться двадцать четыре часа в сутки, ставит перед разработчиками ряд интересных проблем, связанных с масштабируемостью и устойчивостью системы.
Оптимизация показов — большой процесс, одной из частей которого является сохранение и анализ цепочки событий, связанных с жизненным циклом баннера — показ, клик, конверсия, … всё это начинается с сохранения записей о событиях. Каждое из событий происходит на одном из множества серверов, причем, по понятной причине мы стараемся обслужить всю цепочку в одном месте — в этом случае не нужно заботиться о том как собрать в целое разбросанные части. Но в реальной жизни случается что угодно — сервера падают, сеть не работает, софт апгрейдится или перегружен — в общем, по многим причинам обслуживание последовательных событий иногда происходит на разных серверах и даже в разных датацентрах и к этому нужно быть готовым.
Задача которую нужно было решать — каким образом хранить, искать, модифицировать информацию о последовательности событий при следующих условиях:
- события могут происходить на разных серверах и в разных датацентрах (восточный и западный берег США, Европа)
- интервал между событиями — от долей секунды до нескольких дней
- к моменту получения завершающего события (например конверсия) информация обо всей цепочке должна быть на руках
- время жизни информации — примерно десять дней, после чего она должна быть удалена, желательно автоматически, через TTL
- темп чтения/записи событий — сотни или тысячи в секунду
- Время ответа: желательное — до 10мс, допустимое — в пределах 50мс, максимальное — до 100мс
- информация должна быть доступна «всегда» — независимо от аварий железа, сети, апгрейдов
- система должна легко масштабироваться: добавление новых серверов, датацентров должно происходить прозрачно для остальных сервисов (допустима деградация времени ответа в заданных пределах).
Последние два пункта очень важны для бизнеса и просто жизненно важны для опс инженеров если они хотят спокойно выполнять свои обязанности днём, и спокойно спать ночью.
Читать полностью »