Обновить
0
0
Роман Белкин@skullodrom

DB, Econimics, MBTI, Science, Stock exchange

Отправить сообщение
Это не крутой разработчик.

Он просто религиозен как и большинство разработчиков, он свято верит в NoSQL =)
Но это несомненно минус, в этом я согласен.

Ключевая фраза горизонтальное масштабирование. Использование sky tools в интернете хорошо описано. Если кратко то смысл в том что данные в таблицах делятся по серверам, прозрачно для клиента.

Почитаю. А кроме Скайпа кто ни будь использует эту технологию?

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

Я в данном месте имел в виду шардинг. Шардинг с избыточностью заменяет репликацию.

Совершенно не обязательно. Никто не мешает вам с него читать. У MySQL даже есть классическая схема когда делают много слейвов и с них читают, а пишут только в один.

Вот я про это и говорю, что писать нельзя в StandBy, только запросами по ней бегать. Клиент подключается к общему инстансу за которым стоит Master and StandBy, и работать в одной в одной сессии он может только с одной БД. Так что Master может задыхаться от нагрузки, но StandBy при этом может работать в холостую.
А возможность бегать Select на StandBy я считаю не очень большим приемуществом.

>Проблема в том, что NoSQL решение от PostgreSQL было как-то быстрее многих чистых NoSQL.
Я про это и говорю, что NoSQL однозначно следует использовать только на Больших Данных.

Значит, его крутость ограничена Java и C#, и прислушиваться к его мнению за их пределами не надо.

Не совсем так, он реально очень крутой разработчик, хорошо разбирается в Java и C# и NoSQL.
Просто он в свое время поддался эйфории, что обычным SQL базам пришел конец.

Вы готовы доказать это утверждение для всех видов NoSql-решений? Для графовых БД, например?

Не корректный вопрос. Если вы мне достанете дремучую NoSQL базу из ларца, это ничего не значит.
И вы не внимательно читали мою статью, я здесь принципиально не обсуждаю графовые БД

А вы хотите сказать, что репликация в NoSql бесплатна?

Да, вы правы, здесь я не корректно выразился. Надо убрать этот пункт! Ведь чтобы синхронизировать 3 ноды Hadoop на которых находятся одно и те же данные тоже требуется ресурсов. В HDFS нет update, так что можно сказать синхронизировать нечего, а Insert он изначально распределяется. А вот HBase поддерживает update. Если честно не знаю нюансов синхронизации. Вы не в курсе?
Спасибо за информацию!

Если у вас большой проект вам потребуются профессионалы. И они уж явно будут знать как разработать в том числе и БД. Так что очень сомнительный довод.

У меня есть крутой разработчик 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
Спасибо за минусы!
Поднимите мне рейтинг пожалуйста, я теперь не могу больше писать статьи (((
Мускул не моя стихия.
Вы это к слову добавили, или и правла верить, что Мускул или Постгре ничем не хуже Оракла?
На счет надежности вы в целом правы если брать Экзадату. А если рассматривать софт отдельно, разве в Постге пропадают данные?

А вот на счет поддержки, я вам скажу опираясь на свой 10 летний опыт, поддержка потребовалась всего 1 раз и то она не смогла помочь. А вот ко всем остальным продуктам Oracle я бы рекомендовал покупать поддержку.
На счет первого ничем помочь не могу, за 15 лет работы в IT никогда не сталкивался с графами.

на счет второго, еще пока ни одной статьи не видел)
Не для всех, но во многом прав.
nosql-database.org/
Я не случайно это выделил, Терадата не MVCC
Спасибо, печально что кроме граф-ориентированных больше нигде нет
да, согласен. Лучший язык разработки тот, который знает программист.
Так какие NoSQL бд позволяют делать ручной шардинг?
Если стоит задача объединения таблиц ручной шардинг единственное спасение от провала в производительности. Нужно сделать так, что бы шарды двух соединяемых таблиц оказались на одной ноде.
Это уже тема отдельного холивора Оракл против Постгре.
Ну например Оракл в 12.0.1.2 стал in-memory, и я уверен еще тысячи мелких и возможно крупных отличий. Например бэкап постгре убивает производительность очень сильно.

Но тем не менее, большинство предпочитают покупать Оракл, значит есть в этом смысл.
Кстати, один из самых узких моментов, который мне не нравится, это невозможность ручной настройки шардинга. Не подскажите, в какой NoSQL буду он есть, а в какой нет?
Ну я описывал недостатки RDBMS, а вы можно сказать дополнили мою статью недостатками NoSQL =)
Размеры БД достаточно условны в пунктах 3 и 4, я пытался просто отразить все фичи Оракла в одной фразе. Не секрет, что Оракл самая богатая СУБД. Есть же еще фактор кривости рук, умение создавать агрегаты, например и прочие тысячи фич!

Все остальное из личного опыта.

Информация

В рейтинге
Не участвует
Откуда
Praha, Hlavni Mesto Praha, Чехия
Дата рождения
Зарегистрирован
Активность