Зачем я пишу эту статью? Во-первых я хотел бы внести свой вклад в понимание людьми сути nosql и того, почему выбирать такой тип хранилища нужно осознанно. Во-вторых, я буду рад встретить единомышленников, противников и, возможно, подискутировать. А если Вам понравилась эта статья, то буду рад услышать вопросы, которые можно раскрыть более подробно в новых статьях:)
Несмотря на то, что nosql решений сейчас тьма, люди неохотно переходят на новые типы хранилищ. Правильно ли это? На мой взгляд – да. И я постараюсь сказать почему, на примере разных nosql хранилищ, которые встретились на моём профессиональном пути.
Доброго всем дня. Это первая моя «проба пера» в большом издании, надеюсь, что получится интересно:) О самом термине nosql написано вот в этой статье, а мы обратимся к примерам из жизни и попробуем сделать выводы.
Рассмотрим самые популярные СУБД: MySql, PostgreSql, Oracle. Очень много различий, но все трое – отлаженные реляционные бд с богатыми возможностями. Они позволяют создать системы документооброта, банковские приложения и сайты-визитки для маленького кафе. Это общее решение почти любой вашей задачи.
С какими проблемами встречается начинающий разработчик, встретив свою первую SQL базу данных?
И всё, после этого человек не просто освоит одну базу данных, он освоит семейство баз данных и с лёгкостью перейдёт, например, с Mysql на Oracle. (забудем на минутку про PL/SQL и другие важные различия). А если еще использовать ORM… красота.
Вот эта мнимая простота может сыграть злую шутку. Например: при отладке 5ти строчного запроса в Oracle, в попытке сделать его оптимальнее. Тут вот и начинаешь понимать, что бесплатный сыр бывает только в мышеловке.
И тем не менее: это удобство отбора информации, с помощью огромного количества средств языка запросов, – разве не счастье?
Скажу честно, больше 2 лет, как не касался серьёзно mysql, oracle. И дальше я опишу, что отвлекло меня и переманило…
И пусть она требует SQL решение для работы, но всё-таки я считаю alfresco моей первой nosql базой данных.
Что нужно изучить человеку, который впервые садится за разработку на базе этой замечательной платформы? Да, собственно, всё :)
Она совершенно другая. Структуры данных в ней описываются с помощью xml. Связи задаются с помощью, так называемых, ассоциаций. Например: запись, в ней список комментариев – это ассоциации. А еще есть наследование моделей. Одна «таблица» может наследоваться другой.
Бытует мнение, что nosql решение – это обязательно быстрое хранилище. Но alfresco – очень медленное хранилище. Очень-очень. Из недостатков я могу назвать еще и API запросов. Обращаться к хранилищу нужно двумя способами: ассоциации и объекты по id получать через java api, а более сложные запросы с выборкой по атрибутам и ассоциациям через Lucene Query Engine. Выглядят запросы страшно, но я написал простую обёртку над движком запросов, которая позволяла строить запросы как-то так:
И всё-равно это замечательная вещь, потому что на ней очень удобно писать системы документооборота, с большими и сложными бизнес-процессами, по которым документы будут путешествовать, «ночуя» то у одного пользователя, то у другого. Пока не придут, наконец, к какому-то итогу. Например к резолюции: done.
Тогда это было начало версии 3, в 2011 вышла 4. Добавилось много вкусного, наверняка производительность улучшилась, но меня слишком увлекли новые хранилища…
Это моя любовь, которой я не изменяю до сих пор. Коллеги не питали особого восторга насчёт неё, но я до сих пор считаю, что это всё от недостатка RAM на серверах. Естественно, когда речь идёт о 500 млн. строк с блобами на сервер, оперативной памяти нужно использовать побольше, чем 8 гб… нода иногда висла с концами.
Зато… очень быстрая запись, быстрое чтение. Полный контроль над данными, уверенность в том, что база не будет затыком по скорости записи или чтения. Я до сих пор использую её в своих собственных проектах и она меня еще не подводила. Отличительная особенность этой базы еще и в том, что убить её сложно. Я никогда не боюсь за то, что сервер вырубится и мне придётся делать restore, как это происходит, например, с MongoDb с настройками по умолчанию.
Запросы к бд делаются с помощью thrift api, который весьма страшен на вид. В нём отсутствуют все необходимые удобства типа пула коннектов. Мы кладём набор байтов, получаем, по сути, набор байтов. Эту проблему я решил также, как и в случае с Alfresco, только более масштабно: пришлось написать ORM фреймворк, который стал надстройкой над thrift, и при этом не накладывал ограничений по производительности. Были и open source альтернативы велосипеду, но все они показались неудобными в контексте решаемых задач.
Спасибо тимлиду и терпеливым коллегам, которые самоотверженно начали использовать мой продукт и сразу накидали тонну баг репортов:))
И всё-таки cassandra всё еще жрала память и висла при её недостатке…
Моё знакомство с ним было коротким. Почитал на хабре — прикольно. Почитал на сайте — классно. Установил, начал тестировать. Во-первых смутило отсутствие необходимого функционала по запросам к бд. Во-вторых на записи 20 млн. строк база повела себя очень странно. Она просто умерла. Перезапущенная база вела себя еще более странно: с 20 млн. строк на борту она загружалась 10 минут, зачем-то насилуя на 100% только одно ядро из четырёх.
Это было моё личное исследование, поэтому тратить время на эту бд я больше не хотел.
Спасением показалась эта база данных, так как на миллиарде записей на сервер она была не очень требовательна к памяти, да и по записи была очень быстра. Хотя, конечно же, скорость записи там зависит исключительно от выбранного timeout’a сброса на диск. Thrift api после cassandra не вызвал проблем, оставалось просто добавить поддержку hypertable в orm.
Но эта база была настолько падучей, а логи настолько неинформативными, что можно было только диву даваться, как только продукт можно было называть stable. Попытки найти коллег по проблемам в сети — ничего не давали. Можно было просто сделать рестарт и не дождаться базу никогда. А поднимать её надо было с бубном: перезагрузить 2 раза, удалить логи, перезагрузить еще 2-3 раза. Или 5 раз. Хотя проблемы проявились не сразу и она успела почти что уйти в production. В общем не вариант…
Грустные лица коллег, грустный я. Nosql не решил наших задач. Всё было напрасно. Скрепя сердце мы потестировали на наших задачах mysql и на 3 млрд записях он показал себя весьма неплохо. Это и вовсе меня расстроило, с мыслями «Как же так! Ведь nosql! Big data!» пришлось поиспользовать Mysql на реальных данных. Естественно: никаких join’ов, сложных связей. Надо сказать, что реальные данные изменили картину и одну из задач с mysql решить так и не вышло. То есть совсем. Запрос на 4 секунды — это за гранью. Даже при условии жёстко заоптимизированного запроса, на этот раз уже со связями и с использованиями фич SQL. А вот с другой задачей Mysql справился вполне ничего. Главное — правильное количество строк в батче на запись.
В целом: мы были финансово ограничены, много мощных серверов закупить было невозможно. Мы пользовались тем, что дают. И пытались сэкономить как только возможно.
Параллельно с перечисленными бд я использовал/использую еще и эту. Это тоже любимая бд, использовал я её уже в 6ти проектах. В качестве приятностей есть удобный ORM фреймворк на java — Morphia, огромные возможности по выборке данных, масштабируемость и скорость.
Конечно же и тут есть нюансы:
На мой взгляд, эта база данных замечательна как переходная — между SQL решением и миром Nosql. Какие преимущества этой бд есть лично для меня? Schema free, простота запросов, документоориентированность, масштабируемость. Мне приятна сама парадигма, которую носит эта бд.
И тем не менее: из 6ти проектов на монго, можно было бы написать 3-4 на mysql и не париться. Я написал их на монго только потому, что мне нравится монго.
Эту вещь я начал использовать недавно — около 3х месяцев назад, с переходом на новое место работы. Hadoop — это экосистема решений по хранению и обработке огромных объёмов данных. При осознании сути map-reduce и hadoop, поражает простота алгоритмов и принципов, положенных в начале этого решения. Тем не менее эта простота помогает обработать 200 гигабайт текстовой информации так, будто бы вы обрабатываете небольшую статью. Всё дело в том, что набор простых идей даёт по итогу быстрое, простое решение. А если вам кажется, что данные обрабатываются недостаточно быстро — добавьте нод в кластер.
Разумеется, что понимание самой сути, исследование исходников hadoop, реализация первых задач расчёта занимают некоторое время.
Главным же сюрпризом этого решения для меня стало то, что база данных может быть вообще не нужна, если вам нужно хранить и перерабатывать действительно большие данные.
В качестве вывода я бы хотел высказать своё личное мнение по поводу всего этого:
Нет единого решения для всех задач. Наиболее близко к таковому, несмотря ни на что, — sql решение. Каждое nosql хранилище — это инструмент, который решает только определённый круг задач, при этом требует работы напильником, изучения внутренностей и тщательную настройку, а то и написание своего клиента.
Дополнение к выводу:
Подумать надо прежде всего потому, что серебряной пули не будет. И как бы ни был понятен мануал к базе данных, количество сюрпризов от этого не уменьшится. Текущие nosql решения — молодые и от того не лишённые недостатков инструменты. Тем не менее некоторые из них вполне готовы к production использованию, например: mongodb, redis, hbase, cassandra.
А вот придти к ответу на вопрос «что использовать» и в каком случае, на мой взгляд, нужно самому. Путём тестирования и исследования решений вашей конкретной задачи.
Несмотря на то, что nosql решений сейчас тьма, люди неохотно переходят на новые типы хранилищ. Правильно ли это? На мой взгляд – да. И я постараюсь сказать почему, на примере разных nosql хранилищ, которые встретились на моём профессиональном пути.
Начало истории
Доброго всем дня. Это первая моя «проба пера» в большом издании, надеюсь, что получится интересно:) О самом термине nosql написано вот в этой статье, а мы обратимся к примерам из жизни и попробуем сделать выводы.
Рассмотрим самые популярные СУБД: MySql, PostgreSql, Oracle. Очень много различий, но все трое – отлаженные реляционные бд с богатыми возможностями. Они позволяют создать системы документооброта, банковские приложения и сайты-визитки для маленького кафе. Это общее решение почти любой вашей задачи.
С какими проблемами встречается начинающий разработчик, встретив свою первую SQL базу данных?
- Нужно изучить синтаксис SQL
- Нужно осознать саму суть реляционной модели
- Нужно освоить клиент к базе данных на любимом языке разработки
И всё, после этого человек не просто освоит одну базу данных, он освоит семейство баз данных и с лёгкостью перейдёт, например, с Mysql на Oracle. (забудем на минутку про PL/SQL и другие важные различия). А если еще использовать ORM… красота.
Вот эта мнимая простота может сыграть злую шутку. Например: при отладке 5ти строчного запроса в Oracle, в попытке сделать его оптимальнее. Тут вот и начинаешь понимать, что бесплатный сыр бывает только в мышеловке.
И тем не менее: это удобство отбора информации, с помощью огромного количества средств языка запросов, – разве не счастье?
Скажу честно, больше 2 лет, как не касался серьёзно mysql, oracle. И дальше я опишу, что отвлекло меня и переманило…
Alfresco
И пусть она требует SQL решение для работы, но всё-таки я считаю alfresco моей первой nosql базой данных.
Что нужно изучить человеку, который впервые садится за разработку на базе этой замечательной платформы? Да, собственно, всё :)
Она совершенно другая. Структуры данных в ней описываются с помощью xml. Связи задаются с помощью, так называемых, ассоциаций. Например: запись, в ней список комментариев – это ассоциации. А еще есть наследование моделей. Одна «таблица» может наследоваться другой.
Бытует мнение, что nosql решение – это обязательно быстрое хранилище. Но alfresco – очень медленное хранилище. Очень-очень. Из недостатков я могу назвать еще и API запросов. Обращаться к хранилищу нужно двумя способами: ассоциации и объекты по id получать через java api, а более сложные запросы с выборкой по атрибутам и ассоциациям через Lucene Query Engine. Выглядят запросы страшно, но я написал простую обёртку над движком запросов, которая позволяла строить запросы как-то так:
Query.field(title).eq("Заголовок").and(Query.field(text).like("*текст*")); и жизнь стала краше и веселее. Запрос написал по памяти, но коллеги узнают (привет!:))И всё-равно это замечательная вещь, потому что на ней очень удобно писать системы документооборота, с большими и сложными бизнес-процессами, по которым документы будут путешествовать, «ночуя» то у одного пользователя, то у другого. Пока не придут, наконец, к какому-то итогу. Например к резолюции: done.
Тогда это было начало версии 3, в 2011 вышла 4. Добавилось много вкусного, наверняка производительность улучшилась, но меня слишком увлекли новые хранилища…
Cassandra
Это моя любовь, которой я не изменяю до сих пор. Коллеги не питали особого восторга насчёт неё, но я до сих пор считаю, что это всё от недостатка RAM на серверах. Естественно, когда речь идёт о 500 млн. строк с блобами на сервер, оперативной памяти нужно использовать побольше, чем 8 гб… нода иногда висла с концами.
Зато… очень быстрая запись, быстрое чтение. Полный контроль над данными, уверенность в том, что база не будет затыком по скорости записи или чтения. Я до сих пор использую её в своих собственных проектах и она меня еще не подводила. Отличительная особенность этой базы еще и в том, что убить её сложно. Я никогда не боюсь за то, что сервер вырубится и мне придётся делать restore, как это происходит, например, с MongoDb с настройками по умолчанию.
Запросы к бд делаются с помощью thrift api, который весьма страшен на вид. В нём отсутствуют все необходимые удобства типа пула коннектов. Мы кладём набор байтов, получаем, по сути, набор байтов. Эту проблему я решил также, как и в случае с Alfresco, только более масштабно: пришлось написать ORM фреймворк, который стал надстройкой над thrift, и при этом не накладывал ограничений по производительности. Были и open source альтернативы велосипеду, но все они показались неудобными в контексте решаемых задач.
Спасибо тимлиду и терпеливым коллегам, которые самоотверженно начали использовать мой продукт и сразу накидали тонну баг репортов:))
И всё-таки cassandra всё еще жрала память и висла при её недостатке…
Riak
Моё знакомство с ним было коротким. Почитал на хабре — прикольно. Почитал на сайте — классно. Установил, начал тестировать. Во-первых смутило отсутствие необходимого функционала по запросам к бд. Во-вторых на записи 20 млн. строк база повела себя очень странно. Она просто умерла. Перезапущенная база вела себя еще более странно: с 20 млн. строк на борту она загружалась 10 минут, зачем-то насилуя на 100% только одно ядро из четырёх.
Это было моё личное исследование, поэтому тратить время на эту бд я больше не хотел.
Hypertable
Спасением показалась эта база данных, так как на миллиарде записей на сервер она была не очень требовательна к памяти, да и по записи была очень быстра. Хотя, конечно же, скорость записи там зависит исключительно от выбранного timeout’a сброса на диск. Thrift api после cassandra не вызвал проблем, оставалось просто добавить поддержку hypertable в orm.
Но эта база была настолько падучей, а логи настолько неинформативными, что можно было только диву даваться, как только продукт можно было называть stable. Попытки найти коллег по проблемам в сети — ничего не давали. Можно было просто сделать рестарт и не дождаться базу никогда. А поднимать её надо было с бубном: перезагрузить 2 раза, удалить логи, перезагрузить еще 2-3 раза. Или 5 раз. Хотя проблемы проявились не сразу и она успела почти что уйти в production. В общем не вариант…
Mysql
(просто для примера)Грустные лица коллег, грустный я. Nosql не решил наших задач. Всё было напрасно. Скрепя сердце мы потестировали на наших задачах mysql и на 3 млрд записях он показал себя весьма неплохо. Это и вовсе меня расстроило, с мыслями «Как же так! Ведь nosql! Big data!» пришлось поиспользовать Mysql на реальных данных. Естественно: никаких join’ов, сложных связей. Надо сказать, что реальные данные изменили картину и одну из задач с mysql решить так и не вышло. То есть совсем. Запрос на 4 секунды — это за гранью. Даже при условии жёстко заоптимизированного запроса, на этот раз уже со связями и с использованиями фич SQL. А вот с другой задачей Mysql справился вполне ничего. Главное — правильное количество строк в батче на запись.
В целом: мы были финансово ограничены, много мощных серверов закупить было невозможно. Мы пользовались тем, что дают. И пытались сэкономить как только возможно.
MongoDb
Параллельно с перечисленными бд я использовал/использую еще и эту. Это тоже любимая бд, использовал я её уже в 6ти проектах. В качестве приятностей есть удобный ORM фреймворк на java — Morphia, огромные возможности по выборке данных, масштабируемость и скорость.
Конечно же и тут есть нюансы:
- использовать крайне желательно версию mongo >2
- будьте осторожны с перезагрузками сервера, без завершения работы mongo, если не занимались хорошенько настройкой
- почитайте про mongorestore и журналирование:)
На мой взгляд, эта база данных замечательна как переходная — между SQL решением и миром Nosql. Какие преимущества этой бд есть лично для меня? Schema free, простота запросов, документоориентированность, масштабируемость. Мне приятна сама парадигма, которую носит эта бд.
И тем не менее: из 6ти проектов на монго, можно было бы написать 3-4 на mysql и не париться. Я написал их на монго только потому, что мне нравится монго.
Hadoop
Эту вещь я начал использовать недавно — около 3х месяцев назад, с переходом на новое место работы. Hadoop — это экосистема решений по хранению и обработке огромных объёмов данных. При осознании сути map-reduce и hadoop, поражает простота алгоритмов и принципов, положенных в начале этого решения. Тем не менее эта простота помогает обработать 200 гигабайт текстовой информации так, будто бы вы обрабатываете небольшую статью. Всё дело в том, что набор простых идей даёт по итогу быстрое, простое решение. А если вам кажется, что данные обрабатываются недостаточно быстро — добавьте нод в кластер.
Разумеется, что понимание самой сути, исследование исходников hadoop, реализация первых задач расчёта занимают некоторое время.
Главным же сюрпризом этого решения для меня стало то, что база данных может быть вообще не нужна, если вам нужно хранить и перерабатывать действительно большие данные.
В качестве вывода я бы хотел высказать своё личное мнение по поводу всего этого:
Нет единого решения для всех задач. Наиболее близко к таковому, несмотря ни на что, — sql решение. Каждое nosql хранилище — это инструмент, который решает только определённый круг задач, при этом требует работы напильником, изучения внутренностей и тщательную настройку, а то и написание своего клиента.
Дополнение к выводу:
Подумать надо прежде всего потому, что серебряной пули не будет. И как бы ни был понятен мануал к базе данных, количество сюрпризов от этого не уменьшится. Текущие nosql решения — молодые и от того не лишённые недостатков инструменты. Тем не менее некоторые из них вполне готовы к production использованию, например: mongodb, redis, hbase, cassandra.
А вот придти к ответу на вопрос «что использовать» и в каком случае, на мой взгляд, нужно самому. Путём тестирования и исследования решений вашей конкретной задачи.