Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 79
А огромный минус Java по сравнению с ручной обработкой данных в Excel — необходимость знать Java.
Вот печаль — огорчение.
Вот печаль — огорчение.
Статья будет полезна особенно начинающим пионерам в разработки БД.
Если у вас 600 Терабайт
Если у вас больше 1 Петабайт данных
Очень хорошо сочетается.
Необходимо знать язык SQL и основные принципы RDBMS как транзакции, foreign key, таблицы.
А с NoSQL ничего знать не нужно, я так понимаю? Оно просто работает?
Если у вас большой проект, то вам нужен профессиональный БД разработчик, а это лишний балласт если не будет проектов в будущем.
Если у вас большой проект, то и надо брать разработчика под проект, зачем про будущее-то думать?
А вообще же, все посылки к появлению (и использованию) NoSQL прекрасно изложены в NoSQL Distilled.
Учитывая, сколько может стоить компании неконсистентность вышеупомянутых 600 Терабайт, в принципе 20 миллионов долларов — это немного.
Не говоря уже о том, что числа скорее всего высосаны из пальца.
Да и ценность терабайта лайков и терабайта клиентских данных разная :)
Да и ценность терабайта лайков и терабайта клиентских данных разная :)
Какие цифры высосаны из пальца?
терабайты и петабайты.
Почему для более петабайта данных нужна некая конкретная СУБД? У того же постгреса размер БД не ограничен.
Почему для более петабайта данных нужна некая конкретная СУБД? У того же постгреса размер БД не ограничен.
Ну а почему же все не работают на PostgreSQL, а покупают Оракл и Терадату, никогда не думали? =)
Это сложный вопрос, причин выбора Oracle вместо PostgeSQL масса и не всегда они находятся в технологической плоскости.
Обычно цена
Обычно «кто что умеет». У нас в универе учат ораклу, так ничего неожиданного в том, что выпускники предпочтут оракул.
Второй по популярности аргумент — интеграция, если вся система на базе продуктов MS, то MS SQL там естественный выбор.
А по цене они все в копеечку войдут, в том числе и многомерные базы, и прочие нереляционные.
Второй по популярности аргумент — интеграция, если вся система на базе продуктов MS, то MS SQL там естественный выбор.
А по цене они все в копеечку войдут, в том числе и многомерные базы, и прочие нереляционные.
Ну собственно, Oracle и та же MSSQL заинтересованы, чтобы студенты изучали их СУБД и в перспективе склонили работодателя в «правильную» сторону. Это абсолютно нормальный маркетинг.
Разработчики open source СУБД в маркетинге продукта заинтересованы, думаю, в меньшей степени.
Разработчики open source СУБД в маркетинге продукта заинтересованы, думаю, в меньшей степени.
да, согласен. Лучший язык разработки тот, который знает программист.
Есть Enterprise версия Postgres, совместимая с Oracle.
Как правильно писали выше, вопрос выбора не всегда лежит в технологической плоскости.
Как правильно писали выше, вопрос выбора не всегда лежит в технологической плоскости.
1. Возможностей PostgreSQL не всегда хватает.
2. Оракл больше распространен:
2.1 Легче найти человека который будет это поддерживать. Найти человека который будет поддерживать PostgreSQL — проблема.
2.2 Легче найти утилиты если «что-то пошло не так»
3. Цена иногда решает в другую сторону — продать решение на Оракле можно ороже, чем решение на «бесплатном PostgreSQL»
4. Корпоративные заморочки: у нас УЖЕ есть лицензия на Оракл и Ораклист-затейник — нафиг нам что-то еще.
2. Оракл больше распространен:
2.1 Легче найти человека который будет это поддерживать. Найти человека который будет поддерживать PostgreSQL — проблема.
2.2 Легче найти утилиты если «что-то пошло не так»
3. Цена иногда решает в другую сторону — продать решение на Оракле можно ороже, чем решение на «бесплатном PostgreSQL»
4. Корпоративные заморочки: у нас УЖЕ есть лицензия на Оракл и Ораклист-затейник — нафиг нам что-то еще.
На мой не искушенный взгляд, покупка Терадаты или Оракла лежит в плоскости надежности и поддержки — тогда, когда потеря данных будет стоить много дороже затрат на покупку…
На счет надежности вы в целом правы если брать Экзадату. А если рассматривать софт отдельно, разве в Постге пропадают данные?
А вот на счет поддержки, я вам скажу опираясь на свой 10 летний опыт, поддержка потребовалась всего 1 раз и то она не смогла помочь. А вот ко всем остальным продуктам Oracle я бы рекомендовал покупать поддержку.
А вот на счет поддержки, я вам скажу опираясь на свой 10 летний опыт, поддержка потребовалась всего 1 раз и то она не смогла помочь. А вот ко всем остальным продуктам Oracle я бы рекомендовал покупать поддержку.
>>>
3. Если у вас есть деньги, но вы умеете их считать, вам нужна стабильная, универсальная и простая в разработке БД и данных у вас меньше 10 Терабайт, и вас не пугает сложность администрирование, то берите обычный Oracle
4. Если у вас нет денег, но данных не больше 1 Тб, но вам по прежнему нужна хорошая платформа для разработки БД со сложной логикой, то берите PostgreSQL
На чем основано вот такое четкое разделение? Бенчмарки? Практический опыт?
3. Если у вас есть деньги, но вы умеете их считать, вам нужна стабильная, универсальная и простая в разработке БД и данных у вас меньше 10 Терабайт, и вас не пугает сложность администрирование, то берите обычный Oracle
4. Если у вас нет денег, но данных не больше 1 Тб, но вам по прежнему нужна хорошая платформа для разработки БД со сложной логикой, то берите PostgreSQL
На чем основано вот такое четкое разделение? Бенчмарки? Практический опыт?
Размеры БД достаточно условны в пунктах 3 и 4, я пытался просто отразить все фичи Оракла в одной фразе. Не секрет, что Оракл самая богатая СУБД. Есть же еще фактор кривости рук, умение создавать агрегаты, например и прочие тысячи фич!
Все остальное из личного опыта.
Все остальное из личного опыта.
Что такого не умеет PostgreSQL чего не умеет Oracle ??
Это уже тема отдельного холивора Оракл против Постгре.
Ну например Оракл в 12.0.1.2 стал in-memory, и я уверен еще тысячи мелких и возможно крупных отличий. Например бэкап постгре убивает производительность очень сильно.
Но тем не менее, большинство предпочитают покупать Оракл, значит есть в этом смысл.
Ну например Оракл в 12.0.1.2 стал in-memory, и я уверен еще тысячи мелких и возможно крупных отличий. Например бэкап постгре убивает производительность очень сильно.
Но тем не менее, большинство предпочитают покупать Оракл, значит есть в этом смысл.
ЧТД, размер сам по себе в данном случае не определяет. Фичи — да.
NoSQL всем хороши, но:
1. Необходимо поддерживать связность данных и консистентность — УПС!!!
2. ACID — УПС!!!
3. Аналитика (справедливости ради печаль и среди опенсорсных субд) УПСС!!!
4. Такие отличные «масштабируемые» шардинги… УПССС!!!
5. Аналитические запросы — УПССС!
6. Большие наборы данных с дубликатами УПППС!!!
А в целом, нормальные базы ;)
1. Необходимо поддерживать связность данных и консистентность — УПС!!!
2. ACID — УПС!!!
3. Аналитика (справедливости ради печаль и среди опенсорсных субд) УПСС!!!
4. Такие отличные «масштабируемые» шардинги… УПССС!!!
5. Аналитические запросы — УПССС!
6. Большие наборы данных с дубликатами УПППС!!!
А в целом, нормальные базы ;)
Ну я описывал недостатки RDBMS, а вы можно сказать дополнили мою статью недостатками NoSQL =)
Кстати, один из самых узких моментов, который мне не нравится, это невозможность ручной настройки шардинга. Не подскажите, в какой NoSQL буду он есть, а в какой нет?
То есть вы считаете шардирование по формуле на N серверов без возможности дальнейшего роста без перестроения серверов БД панацеей? :)
Если стоит задача объединения таблиц ручной шардинг единственное спасение от провала в производительности. Нужно сделать так, что бы шарды двух соединяемых таблиц оказались на одной ноде.
Решения есть и весьма неплохие, это наипростейшая из задач, даже на PHP с libevent решаемо.
То, что вы описали, верно тоже не для всех вариантов NoSQL.
Не для всех, но во многом прав.
nosql-database.org/
nosql-database.org/
… или нужно неблокирующее чтение… Покупайте Exadata
ИМХО, сейчас большинство СУБД реализуют MVCC.
Поднимите мне рейтинг пожалуйста, я теперь не могу больше писать статьи (((
Допустим вы разработчик Java, и от вас еще требуют знать какой-то SQL и особенности RDBMS
Гнать такого разработчика в шею. Знание SQL и теории РСУБД как-то более фундаментально и применимо, нежели знание Java.
Если у вас большой проект, то вам нужен профессиональный БД разработчик, а это лишний балласт если не будет проектов в будущем.
Если у вас большой проект вам потребуются профессионалы. И они уж явно будут знать как разработать в том числе и БД. Так что очень сомнительный довод.
Невозможность использовать commodity сервера на больших данных. Если у вас 600 Терабайт, то вам из RDBMS подойдет только Exadata или Teradata.
Давайте честно скажем что не правда. Тот же Skype отлично использовал PostgreSQL использует ли сейчас не знаю. Но SkyTools вполне себе доступны.
Дополнительно я могу рассказать про www.scidb.org/ который внезапно тоже использует кодовую базу PostgreSQL.
2.2. Отказоустойчивость. Без технологии shared-nothing и no single point failer вы вынуждены покупать дорогие сервера, с двойным резервированием всего,
Репликация и быстрое переключение между узлами давно уже есть. И в MySQL и в PostgreSQL. В последней версии PostgreSQL процесс переключения master с одного сервера на другой и обратно существенно упростили.
Ну и дополнительно. В PostgreSQL работают жирные тролли и в последней версии есть NoSQL.
Спасибо за информацию!
У меня есть крутой разработчик Java и C#, он наотрез отказывается пользоваться SQL, говорит, что это прошлый век, что NoSQL во всем лучше, что Твиттер сделал, и мы сделаем. И к сожалению таким разработчиков много.
Может быть, а ссылку можно? Ваша ссылка чисто на форум, что там читать?
Не смог найти Архитектуру Скайпа на Постге. Увидел только что они правили код. Чтобы мне что-то сказать, нужно оценить их архитектуру. Если ей нет в сети в открытом доступе, но она для меня не релевантна. Да и один случай не показателен.
Это да. Но есть нюансы:
1. В NoSQL репликация автоматическая, она обязательная часть архитектуры, а в MySQL и в PostgreSQL её нужно настраивать. В Оракле она настраивается не тривиально для начинающего.
2. StandBy сервер простаивает, а в NoSQL нет
3. Репликация расходует ресурсы Master сервера
Но он не MPP, иначе бы не было Netteza, GreenPlum and AsterData
Если у вас большой проект вам потребуются профессионалы. И они уж явно будут знать как разработать в том числе и БД. Так что очень сомнительный довод.
У меня есть крутой разработчик Java и C#, он наотрез отказывается пользоваться SQL, говорит, что это прошлый век, что NoSQL во всем лучше, что Твиттер сделал, и мы сделаем. И к сожалению таким разработчиков много.
Давайте честно скажем что не правда. Тот же Skype отлично использовал PostgreSQL использует ли сейчас не знаю. Но SkyTools вполне себе доступны.
Дополнительно я могу рассказать про www.scidb.org/ который внезапно тоже использует кодовую базу PostgreSQL.
Может быть, а ссылку можно? Ваша ссылка чисто на форум, что там читать?
Не смог найти Архитектуру Скайпа на Постге. Увидел только что они правили код. Чтобы мне что-то сказать, нужно оценить их архитектуру. Если ей нет в сети в открытом доступе, но она для меня не релевантна. Да и один случай не показателен.
Репликация и быстрое переключение между узлами давно уже есть. И в MySQL и в PostgreSQL. В последней версии PostgreSQL процесс переключения master с одного сервера на другой и обратно существенно упростили.
Это да. Но есть нюансы:
1. В NoSQL репликация автоматическая, она обязательная часть архитектуры, а в MySQL и в PostgreSQL её нужно настраивать. В Оракле она настраивается не тривиально для начинающего.
2. StandBy сервер простаивает, а в NoSQL нет
3. Репликация расходует ресурсы Master сервера
Ну и дополнительно. В PostgreSQL работают жирные тролли и в последней версии есть NoSQL.
Но он не MPP, иначе бы не было Netteza, GreenPlum and AsterData
У меня есть крутой разработчик Java и C#, он наотрез отказывается пользоваться SQL, говорит, что это прошлый век, что NoSQL во всем лучше
Значит, его крутость ограничена Java и C#, и прислушиваться к его мнению за их пределами не надо.
В NoSQL репликация автоматическая, она обязательная часть архитектуры,
Вы готовы доказать это утверждение для всех видов NoSql-решений? Для графовых БД, например?
Репликация расходует ресурсы Master сервера
А вы хотите сказать, что репликация в NoSql бесплатна?
Значит, его крутость ограничена Java и C#, и прислушиваться к его мнению за их пределами не надо.
Не совсем так, он реально очень крутой разработчик, хорошо разбирается в Java и C# и NoSQL.
Просто он в свое время поддался эйфории, что обычным SQL базам пришел конец.
Вы готовы доказать это утверждение для всех видов NoSql-решений? Для графовых БД, например?
Не корректный вопрос. Если вы мне достанете дремучую NoSQL базу из ларца, это ничего не значит.
И вы не внимательно читали мою статью, я здесь принципиально не обсуждаю графовые БД
А вы хотите сказать, что репликация в NoSql бесплатна?
Да, вы правы, здесь я не корректно выразился. Надо убрать этот пункт! Ведь чтобы синхронизировать 3 ноды Hadoop на которых находятся одно и те же данные тоже требуется ресурсов. В HDFS нет update, так что можно сказать синхронизировать нечего, а Insert он изначально распределяется. А вот HBase поддерживает update. Если честно не знаю нюансов синхронизации. Вы не в курсе?
Не совсем так, он реально очень крутой разработчик, хорошо разбирается в Java и C# и NoSQL. Просто он в свое время поддался эйфории, что обычным SQL базам пришел конец.
Это значит, что он недостаточно хорошо разбирается в NoSql (иначе бы он знал про их недостатки) и вообще не разбирается в RDBMS. Сочетание этих двух факторов говорит нам, что к его мнению в области БД прислушиваться либо не стоит, либо стоит ограничено.
И вы не внимательно читали мою статью, я здесь принципиально не обсуждаю графовые БД
Я как раз внимательно ее читал. Там написано «В статье не рассматриваются специализированные базы данных для векторных, графический и прочих нестандартных форматов.». К графовым БД это отношения не имеет.
У меня есть крутой разработчик Java и C#, он наотрез отказывается пользоваться SQL, говорит, что это прошлый век, что NoSQL во всем лучше, что Твиттер сделал, и мы сделаем. И к сожалению таким разработчиков много.
Это не крутой разработчик. Крутому разработчику без разницы на чем писать и SQL он использует и понимает зачем это надо. А это скажем крутой кодер. И да специально для таких людей придуманы ORM. Правда при этом писать обвязку ORM такой человек не должен.
Может быть, а ссылку можно? Ваша ссылка чисто на форум, что там читать?
Не смог найти Архитектуру Скайпа на Постге. Увидел только что они правили код. Чтобы мне что-то сказать, нужно оценить их архитектуру. Если ей нет в сети в открытом доступе, но она для меня не релевантна. Да и один случай не показателен
Ключевая фраза горизонтальное масштабирование. Использование sky tools в интернете хорошо описано. Если кратко то смысл в том что данные в таблицах делятся по серверам, прозрачно для клиента.
В NoSQL репликация автоматическая, она обязательная часть архитектуры, а в MySQL и в PostgreSQL её нужно настраивать. В Оракле она настраивается не тривиально для начинающего.
Вообще говоря не обязательно автоматическая и тоже требует настройки. А так же требует понимания как она работает иначе вы можете словить мноого проблем, когда окажется что репликация работала не так как вы ожидали.
2. StandBy сервер простаивает, а в NoSQL нет
Совершенно не обязательно. Никто не мешает вам с него читать. У MySQL даже есть классическая схема когда делают много слейвов и с них читают, а пишут только в один.
Репликация расходует ресурсы Master сервера
Не столько чтобы это вообще учитывать. И да в случае NoSQL тоже расходуется.
Но он не MPP, иначе бы не было Netteza, GreenPlum and AsterData
Проблема в том, что NoSQL решение от PostgreSQL было как-то быстрее многих чистых NoSQL.
PS У вас много того самого NoSQL is WebScale!.
Это не крутой разработчик.
Он просто религиозен как и большинство разработчиков, он свято верит в NoSQL =)
Но это несомненно минус, в этом я согласен.
Ключевая фраза горизонтальное масштабирование. Использование sky tools в интернете хорошо описано. Если кратко то смысл в том что данные в таблицах делятся по серверам, прозрачно для клиента.
Почитаю. А кроме Скайпа кто ни будь использует эту технологию?
Вообще говоря не обязательно автоматическая и тоже требует настройки. А так же требует понимания как она работает иначе вы можете словить мноого проблем, когда окажется что репликация работала не так как вы ожидали.
Я в данном месте имел в виду шардинг. Шардинг с избыточностью заменяет репликацию.
Совершенно не обязательно. Никто не мешает вам с него читать. У MySQL даже есть классическая схема когда делают много слейвов и с них читают, а пишут только в один.
Вот я про это и говорю, что писать нельзя в StandBy, только запросами по ней бегать. Клиент подключается к общему инстансу за которым стоит Master and StandBy, и работать в одной в одной сессии он может только с одной БД. Так что Master может задыхаться от нагрузки, но StandBy при этом может работать в холостую.
А возможность бегать Select на StandBy я считаю не очень большим приемуществом.
>Проблема в том, что NoSQL решение от PostgreSQL было как-то быстрее многих чистых NoSQL.
Я про это и говорю, что NoSQL однозначно следует использовать только на Больших Данных.
Он просто религиозен как и большинство разработчиков, он свято верит в NoSQL =)
Но это несомненно минус, в этом я согласен.
Религия плохо помогает при разработке.
Почитаю. А кроме Скайпа кто ни будь использует эту технологию?
Много кто. Если вы про нее не слышали, это не значит что ее не существует.
Я в данном месте имел в виду шардинг. Шардинг с избыточностью заменяет репликацию.
Избыточность и есть репликация. В любом случае ситуацию у нас умер узел надо его заменить а в процессе его замены еще умер другой надо не забывать рассматривать.
Клиент подключается к общему инстансу за которым стоит Master and StandBy, и работать в одной в одной сессии он может только с одной БД.
Для решения этой проблемы существуют специальные прокси.
А возможность бегать Select на StandBy я считаю не очень большим приемуществом.
А это зависит от профиля нагрузки.
Я про это и говорю, что NoSQL однозначно следует использовать только на Больших Данных.
Большинство кто пытается его использовать базу то на 100 гб не видели не то что на 1 тб.
Для решения этой проблемы существуют специальные прокси.
Т.е. запросы select направляются на StandBY, а запросы Update, Delete, Insert на Master?
А чтоб будет если сделать select еще не реплецированных данных?
>Большинство кто пытается его использовать базу то на 100 гб не видели не то что на 1 тб.
Я думаю вопрос в выборе базы на 100 Гб это вопрос предпочтения разработчиков. Кому что нравится.
Я думаю вопрос в выборе базы на 100 Гб это вопрос предпочтения разработчиков. Кому что нравится.
Плохая, очень плохая политика.
Политика то может и плоха, но это общеизвестный факт. Лучший язык программирование, этот тот который знает программист.
Задуматься о смене продукта, т.е. выйти из зоны комфорта, стоит, если твой продукт не справляется с задачами, как например Оракл не справился со 200 Терабайтами в Билайне.
Вот моя статья об этом
habrahabr.ru/post/235465/
Задуматься о смене продукта, т.е. выйти из зоны комфорта, стоит, если твой продукт не справляется с задачами, как например Оракл не справился со 200 Терабайтами в Билайне.
Вот моя статья об этом
habrahabr.ru/post/235465/
Вообще-то над программистами еще должен быть архитектор или другой ответственный за принятие решений этого уровня человек, который должен сначала сравнить продукты по объективным возможностям, а только потом оглядываться на опыт программистов. Иными словами, опыт доступных разработчиков — это всего лишь один из множества критериев, влияющих на архитектурные решения.
Да, это хорошая практика!
Но есть еще фактор зоопарка и имеющихся ресурсов. Например у вас есть большой проект на Оракле. А потом появились маленькие, понятно что их можно сделать и на MySQL, но выбирают Оракл, т.к. и программисты уже есть в штате, и не хочется расширять зоопарк ПО.
Но есть еще фактор зоопарка и имеющихся ресурсов. Например у вас есть большой проект на Оракле. А потом появились маленькие, понятно что их можно сделать и на MySQL, но выбирают Оракл, т.к. и программисты уже есть в штате, и не хочется расширять зоопарк ПО.
Это до тех пор, пока стоимость лицензий не считают.
Поверьте, Оракл как наркотик, стоит на него залезть, слезть уже сложно ))
Да я верю. Но деньги считать все равно нужно.
Есть хитрости
1) Можно получить скидку от Оракла за вторую покупку
2) Oracle SE One можно официально купить за 900 баксов
3) Если ты не хранишь данные в базе, а используешь её как AUX ETL, например, то платить за лицензии не нужно
4) Можно в конце концов купить одни лицензии, а железа поставить больше, никто проверять не будет
1) Можно получить скидку от Оракла за вторую покупку
2) Oracle SE One можно официально купить за 900 баксов
3) Если ты не хранишь данные в базе, а используешь её как AUX ETL, например, то платить за лицензии не нужно
4) Можно в конце концов купить одни лицензии, а железа поставить больше, никто проверять не будет
MySQL после Oracle это как серпом по яйцам. Но вообще если у вас просто добавляется еще одна база данных, то это не проблема. А вот если надо ее ставить то включаются такие факторы как сопровождение и стоимость решения.
А чтоб будет если сделать select еще не реплецированных данных?
Тоже самое что и в случае NoSQL ничего не вернет. Вообще странный вопрос так-как большинство NoSQL решений ACID не включают и целостность данных это не их головная боль.
Я думаю вопрос в выборе базы на 100 Гб это вопрос предпочтения разработчиков. Кому что нравится.
В твиттере уже так выбирали ага.
Шардинг с избыточностью заменяет репликацию.
Шардинг не заменяет репликацию. Шардинг и репликация это ортогональные понятия.
А возможность бегать Select на StandBy я считаю не очень большим приемуществом.
А зря, потому что есть много систем, где нагрузка на чтение сильно превышает нагрузку на запись, и их балансировка таким образом радикально повышает производительность.
Я про это и говорю, что NoSQL однозначно следует использовать только на Больших Данных.
Если вкратце, то нет. А если долго, то надо начинать с вашего определения «больших данных», NoSql, и выяснения, вы имели в виду, что «только для больших», или «для больших — однозначно, для других — нет» и так далее.
Шардинг не заменяет репликацию. Шардинг и репликация это ортогональные понятия.
Я имел в виду шардинг с избыточностью, я выше об этом написал. В Hadoop меньше двойной избыточности мало кто в промышленных проектах делает.
А зря, потому что есть много систем, где нагрузка на чтение сильно превышает нагрузку на запись, и их балансировка таким образом радикально повышает производительность.
Ну да, согласен, для некоторых может быть полезна. Но сам факт ручного постоянно переключаться, не очень удобен, по сравнению с автоматической балансировкой нагрузки
Если вкратце, то нет. А если долго, то надо начинать с вашего определения «больших данных», NoSql, и выяснения, вы имели в виду, что «только для больших», или «для больших — однозначно, для других — нет» и так далее.
Согласен, я не корректно выразился. Я лично считаю, что NoSQL MPP однозначно имеет смысл на Больших данных, а вот если это не большие данные, то целесообразность применения Hadoop уже переходит в плоскость предпочтения. Я вот все мелкие задачи делаю на Оракле, хотя и Постгре тоже с ними справится.
Но сам факт ручного постоянно переключаться, не очень удобен, по сравнению с автоматической балансировкой нагрузки
А нет никакого «ручного постоянно», есть просто разделение потоков на чтение и на запись. CQRS.
а вот если это не большие данные, то целесообразность применения Hadoop уже переходит в плоскость предпочтения.
Вы все время забываете, что NoSql — это не только Hadoop, и тем более не только MPP. NoSql — это (будем честными, весьма бессмысленный в своей общности) класс разнообразных хранилищ. Например, любая документо-ориентированная (или key-value) база данных — это NoSql, но никакого MPP там может и не быть при этом.
А нет никакого «ручного постоянно», есть просто разделение потоков на чтение и на запись. CQRS.
Только для тех запросов для которых отстование в репликации на несколько минут не кретично.
Вы все время забываете, что NoSql — это не только Hadoop, и тем более не только MPP. NoSql — это (будем честными, весьма бессмысленный в своей общности) класс разнообразных хранилищ. Например, любая документо-ориентированная (или key-value) база данных — это NoSql, но никакого MPP там может и не быть при этом.
Согласен, это мой пробел, который я не очень то стремлюсь заполнять. Я специализируюсь в основном только на DWH, BI, ETL, Big Data.
Только для тех запросов для которых отстование в репликации на несколько минут не кретично.
В нагруженных системах такие встречаются регулярно. У нас тут отставание в день на одном проекте — и ничего.
Согласен, это мой пробел, который я не очень то стремлюсь заполнять. Я специализируюсь в основном только на DWH, BI, ETL, Big Data.
Vожет быть тогда не стоит писать статьи про NoSql, а стоит говорить конкретно про Hadoop?
Ни в коем случае не агитирую, NoSQL в ряде случаев просто удобен при работе с простыми не сложно структурированными данными. Например, анализ звонков в колл-центре или билиннг простенький какой. Сам писал такие программы и было удобнее и быстрее без RDBMS.
Но если данные хорошо структурированы и сама архитектура комплекса продумана и имеет сложную сетевую модель, то без реляционной модели тут никуда. И знание SQL — тут не самое сложное. Метаданные — это ядро системы, их не должно быть петабайты. А всякие плоские и зачастую архивные и отчетные данные лучше хранить во внешних хранилищах. Современные СУБД это поддерживают. Не надо всякий мусор держать в дорогой RDBMS. Никто не хранит дома старые вещи — обычно для этого есть сарай.
Если правильно продумать архитектуру проекта то будет и небольшие объем метаданных на RDBMS и петабайты, как внешние таблицы для них, которые ПО может редактировать отдельно.
Но если данные хорошо структурированы и сама архитектура комплекса продумана и имеет сложную сетевую модель, то без реляционной модели тут никуда. И знание SQL — тут не самое сложное. Метаданные — это ядро системы, их не должно быть петабайты. А всякие плоские и зачастую архивные и отчетные данные лучше хранить во внешних хранилищах. Современные СУБД это поддерживают. Не надо всякий мусор держать в дорогой RDBMS. Никто не хранит дома старые вещи — обычно для этого есть сарай.
Если правильно продумать архитектуру проекта то будет и небольшие объем метаданных на RDBMS и петабайты, как внешние таблицы для них, которые ПО может редактировать отдельно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Недостатки RDBMS или RDBMS vs NoSQL