NoSQL *

Внимание: тег «юмор».

И в заключение. Мы пришли к выводу, что MySQL — это прекрасная база данных для нашего сайта. Вопросы?

Да, у меня есть вопрос. Почему вы не использовали MongoDB? MongoDB — это горизонтально масштабируемая база данных, она не использует SQL или JOINы, поэтому обладает высокой производительностью.

Это прекрасный вопрос. Мы изучили несколько NoSQL баз данных и поняли, что все варианты пока ещё незрелы для применения на работающих проектах. MySQL — это проверенная база данных, которая используется во всём мире и имеет все необходимые нам функции.

Но она не масштабируется. Все знают, что реляционные базы данных не масштабируются, потому что они используют JOINы и записывают на диск.

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

Я поставил перед собой цель показать возможности Redis с помощью примеров кода. После публикации приму любые предложения по улучшению материала.

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

Ключи

Redis — хранилище данных в формате «ключ-значение». Факты о ключах:

• Ключи в Redis — бинарно-безопасные (binary safe) строки.
• Слишком длинные ключи — плохая идея, не только из-за занимаемой памяти, но так же и в связи с увеличением времени поиска определенного ключа в множестве в связи с дорогостоящим сравнением.
• Хорошая идея — придерживаться схемы при построении ключей: «object-type:id:field».

Типы данных Redis

• Строки (strings). Базовый тип данных Redis. Строки в Redis бинарно-безопасны, могут использоваться так же как числа, ограничены размером 512 Мб.
• Списки (lists). Классические списки строк, упорядоченные в порядке вставки, которая возможна как со стороны головы, так и со стороны хвоста списка. Максимальное количество элементов — 2³² — 1.
• Множества (sets). Множества строк в математическом понимании: не упорядочены, поддерживают операции вставки, проверки вхождения элемента, пересечения и разницы множеств. Максимальное количество элементов — 2³² — 1.
• Хеш-таблицы (hashes). Классические хеш-таблицы или ассоциативные массивы. Максимальное количество пар «ключ-значение» — 2³² — 1.
• Упорядоченные множества (sorted sets). Упорядоченное множество отличается от обычного тем, что его элементы упорядочены по особому параметру «score».

Про типы данных Redis есть отдельная хорошая статья: «Структуры данных, используемые в Redis».

9 декабря в Екатеринбурге пройдет первая в России конференция, посвященная NoSQL-хранилищу Cassandra. Мы уже сформировали программу CassandraConf.ru и приглашаем присоединиться как опытных разработчиков, так и тех, кто хочет познакомиться с Cassandra впервые!

Участие в конференции бесплатное — приезжайте!

Под катом — программа мероприятия и подробности

Вы, возможно, помните как несколько лет назад стремительно стали набирать популярность NoSQL-базы данных (MongoDB, DynamoDB и другие). Многие пророчили смерть классических реляционных баз данных, торжество новых парадигм и всеобщее счастье в мире. И вы, возможно, в курсе того, как в последний год (или около того) наблюдается откат этой эйфории — выходят статьи типа «Broken by Design: MongoDB Fault Tolerance» и Why You Should Never Use MongoDB. Народ на Хабре на Тостере интересуется — «А почему же Монгу критикуют?», на что получает ответы «перерекламировали», «серебрянной пули нет», «надо выбирать базу данных по задачам».

Все 3 очевидных варианта — «Использовать реляционную БД», «Использовать NoSQL-БД», «Выбирать БД по задачам проекта» мне не нравятся по причине, высказанной в заголовке статьи.

Чуть больше года назад встала проблема выбора NoSQL решения для проекта. Был ряд определенных требований.

1. Возможность расширения (триггеры, хранимые процедуры);
2. Полнотекстовый поиск;
3. Наличие провайдера для .NET;
4. Поддержка POCO;
5. Возможность развернуть на Windows платформе;
6. Желательно поддержка lucene.net;
7. Желательно поддержка транзакций;
8. Желательно поддержка асинхронных запросов;
9. Желательно map reduce;
10. Желательно наличие документации и сообщества разработчиков.

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

Далеко-далеко, где-то на краю Галактики, я обнаружил весьма впечатляющее NoSQL решение…

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

Маркетинговая затравка от авторов звучит примерно так:

BaseX является очень легковесной, высокопроизводительной и масштабируемой XML базой данных с XPath/XQuery 3.0 процессором, который имеет полную поддержку W3C Update и Full Text спецификаций. Интерактивный и дружественный графический интерфейс позволяет легко изучать ваши XML документы

Звучит весьма вкусно, но реальность, как всегда, больно-больно ударяет по самым незащищенным местам

За последние несколько лет в мире IT появилась модная тенденция – использование всего «облачного» для разработки новых продуктов. Публичных облачных провайдеров не так много, самый популярных среди них – Amazon. Однако многие компании не готовы доверять приватные данные кому-либо, при этом хотят хранить их надежно, и поэтому поднимают частные небольшие облачка.

Любое облако состоит из двух основных компонентов: Единой Точки Входа (ЕТВ) и Облачной Магии (ОМ). Рассмотрим облачное хранилище Amazon S3: в роли ЕТВ используется довольно удобный REST API, а Облачную Магию обеспечивают эльфы, работающие на долларах. Компании, желающие разместить в S3 небольшие видеофайлы или базу данных, предварительно считают на калькуляторе сумму, которую они будут платить в месяц при планируемой нагрузке.

Эта статья про другое облачное хранилище, в котором эльфы питаются Духом Свободы, электричеством и еще им нужно немножечко «кокаина».

Называется это хранилище Elliptics.

Здравствуй, Хабр!

В этой открытой лекции я попытался сжато рассказать и показать полный цикл (full stack) разработки веб-приложений на JavaScript.

Начнем мы с короткого введения в язык, потом в двух словах поговорим о клиентской части, в частности, об MVC фреймворках вроде Angular.js, после чего перейдем на серверную часть: Node.js и MongoDB. В конце обсудим возможность автоматизации разработки и сборки проектов с помощью Grunt.js.



Скачать слайды и исходные коды.

Лекция была записана в офисе компании Chocolife, зрители – разработчики этой компании.

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



В своей прошлой статье я описал базовые понятия и средства для начала работы с тарантулом. В этой статье попробую уделить больше внимания использованию хранимых процедур в Тарантуле на примере одной игровой задачи.

MarkLogic является сервером приложений и любая программа написанная на XQuery для него может получить доступ не только к объектам хранящимся в самой базе данных, но и к файлам находящимся непосредственно на файловой системе.
API предоставляющий доступ к файловой системе в MarkLogic Server не так уж и богат, но имеющихся средств вполне достаточно чтобы зачитывать данные с файловой системы напрямую из XQuery кода и выполнять сохранения файлов на неё.

Еще немного о том как MarkLogic Server хранит данные.

Современные высоконагруженные приложения изменили требования к СУБД — сегодня необходимы эффективные технологии создания cпециализированных решений с гарантированным временем реакции при обработке больших массивов данных. Вместе с тем, несмотря на появление таких относительно новых технологий как NoSQL, потенциал давно существующих подходов реализован еще не полностью.

Интернет проекты с высокой нагрузкой и приложения класса XTP (extreme transaction processing) изменили требования к технологиям СУБД. Приоритетными требованиями стали простота разработки, возможность cпециализации технологии хранимых данных для конкретного проекта, поддержка постоянного времени реакции системы при увеличении нагрузки, обеспечение низкой стоимости масштабирования и стоимости обработки больших объемов данных.

В качестве ответа на новые потребности возникло движение NoSQL — новый класс баз данных, который обещает разработчикам высокую скорость внесения изменений в приложения, низкие затраты на масштабирование и обработку/хранение больших объемов данных, высокую скорость работы на относительно недорогом железе — ценности, которые всегда были важны и для технологий компании InterSystems. Практически всегда NoSQL базы реализуют отличную от привычной парадигму работы приложений с базами данных — переход от концепции интегрирующей СУБД для нескольких приложений к концепции СУБД для одного приложения или одного проекта и больше — отдельной специфичной задачи в рамках проекта.

MarkLogic Server – это документо-ориентированная native XML база данных. Как и в любой документо-ориентированной DB в MarkLogic Server данные можно представить как файлово-фолдерную структуру. Кстати, при доступе к хранилищу через WebDAV данные именно так и представляются. Помимо собственно XML в MarkLogic Server можно хранить и любые бинарные данные в виде файлов.

Внутренне представление XML данных в MarkLogic Server довольно сложное и будет рассмотрено позже. Сейчас же стоит сказать о том, что поместить в MarkLogic Server можно только well formed XML так как хранится он не в виде простого текста, а как объект данных типа XML. Кодировкой внутреннего представления XML данных является Unicode, что избавляет от множества проблем с разными языками. Все Entity в XML данных разворачиваются в цифровые еntity. Если в документе используются только они, то это не доставит никаких проблем, в противном случае MarkLogic Server должен «знать» о всех используемых entity.

Дисклеймер

Эта статья не призывает бросать все, к чему вы привыкли и переходить на использование Couchbase, без оглядки на весь ваш прошлый опыт и косяки, с которыми вы сталкивались, при разработке собственных проектов. Эта статья имеет своей целью быть лишь кратким описанием технологии использования Couchbase Server в связке с PHP и только. Возможно она будет интересна некоторым как описание возможностей, а возможно и как оценочный взгляд на перспективы.

Профилирование – это очень важный аспект при разработке и поддержке почти любого приложения. Не в меньшей мере это относится и к базам данных. Особенно при больших объёмах информации производительность запросов к хранилищу данных является очень критичным. Что же касается производительности запросов в MarkLogic Server и их профилирования, можно сказать что эти вопросы являются одними из самых важных так как XQuery используемый в MarkLogic Server позволяет писать не только очень сложные запросы к самой DB но и довольно сложные приложения.

В последнее время все больше говорят про «NoSQL» — прямо «модный» тренд образовался. «Технологию» начинают активно использовать известные авторитетные компании, в т.ч. в высоконагруженных проектах с немалыми объемами данных — и кто-то восхищается, а кто-то обливает себя бензином и факелом выпрыгивает с 35 этажа с криком: "SQL ACID forever!"


Причем о каком бы продукте не говорили, будь то MongoDB или Cassandra — нередко приходится наблюдать прямо таки религиозную восторженность и трепет, как будто речь идет о чем-то новом и священном.

Хочу поделиться опытом изучения Tarantool. Про все преимущества и особенности самого Тарантула я писать не буду, на эту тему было много статей (например, эта, эта и эта). Этот пост рассказывает о том, как начать работать с тарантулом и про некоторые особенности и вкусности которые можно получить из коробки.

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

Впервые столкнувшись с MapReduce, я продолжительное время искал реальные примеры применения. Пресловутый поиск слов в тексте, встречающийся в каждой второй статье о MapReduce, искомым примером считать не будем. Наконец, на двух курсах по Big Data на Coursera, я нашёл не только живые примеры, но теоретическую подоплёку для более глубокого понимания происходящего. Возможность применить полученный багаж знаний не заставила себя долго ждать.

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

Часть 1.

Моделируем 4 вида NoSQL-баз с помощью GlobalsDB