Изложу мое видение по каким причинам были созданы новые технологии хранения и обработки данные известные как NoSQL и MPP.
Статья будет полезна особенно начинающим пионерам в разработки БД.
В статье не рассматриваются специализированные базы данных для векторных, графический и прочих нестандартных форматов.
Первое, SQL и RDBMS
1.1. Необходимо знать язык SQL и основные принципы RDBMS как транзакции, foreign key, таблицы.
Допустим вы разработчик Java, и от вас еще требуют знать какой-то SQL и особенности RDBMS. Естественно вы ленитесь, пытаетесь как-то отвильнуть.
Да и к тому-же принцип ООП очень не похож на модель данных в RDBMS.
1.2. Если у вас большой проект, то вам нужен профессиональный БД разработчик, а это лишний балласт если не будет проектов в будущем.
Java программистам так и хочется сделать всю бизнес логику на Java в обход SQL и RDBMS.
Второе, Цена
2.1. Невозможность использовать commodity сервера на больших данных. Если у вас 600 Терабайт, то вам из RDBMS подойдет только Exadata или Teradata.
2.2. Отказоустойчивость. Без технологии shared-nothing и no single point failer вы вынуждены покупать дорогие сервера, с двойным резервированием всего,
RAID контроллеров, блоков питания, покупать бесперебойник, дорогие хранилки и так далее.
2.3. Цена лицензий. RDBMS с развитыми возможностями, способные держать сотни терабайт не дешево, особенно appliance решения.
Третье, >=1 Pb данных
3.1. Если у вас больше 1 Петабайт данных, то вам из RDBMS подходит уже только Терадата за 20 млн.$
Тогда как собрать кластер для Hadoop с тройной избыточностью на 1 Петабайт данных сейчас стоит 367 000$ (только сервера с дисками).
На вот таких вот серверах и 4 дисках в RAID 0
www.ulmart.ru/goods/613438
www.ulmart.ru/goods/690535
Правда на электроэнергии разоритесь. Для такого детища потребуется мини электростанция.
Вот собственно по этому и началось это движение NoSQL, Hadoop, MPP. Для решения вышеизложенных особенностей, неудобств, недостатков.
Вывод:
RDBMS по прежнему остаются универсальными БД способными ��ешить любые задачи. Так что советую лишний раз подумать, является ли один из вышеизложенных пунктов для вас критичным. Если нет, то смело берите обычную RDBMS!
Вердикт:
1. Если у вас денег куры не клюют, у вас сложная разработка или нужно неблокирующее чтение и вы любите комфортные условия разработки.
Покупайте Exadata
2. Если у вас денег куры не клюют, не очень сложная разработка, вас не пугает отсутствие хорошего инструментария,
и вы не любите создавать агрегаты, а любите грубую силу full scan то покупайте Терадату
3. Если у вас есть деньги, но вы умеете их считать, вам нужна стабильная, универсальная и простая в разработке БД и данных у вас меньше 10 Терабайт, и вас не пугает сложность администрирование, то берите обычный Oracle
4. Если у вас нет денег, но данных не больше 1 Тб, но вам по прежнему нужна хорошая платформа для разработки БД со сложной логикой, то берите PostgreSQL
5. Если у вас нет навыков SQL и RDBMS, данные слабо-связанные или у вас хороший ETL, который все отлавливает. Не сложные запросы без соединения множества таблиц. Вся логика не в БД. То вам вполне подойдет NoSQL БД, хотя, как я и сказал, RDBMS универсальны, могут все что угодно, если вы умеете ими пользоваться.
Статья будет полезна особенно начинающим пионерам в разработки БД.
В статье не рассматриваются специализированные базы данных для векторных, графический и прочих нестандартных форматов.
Первое, SQL и RDBMS
1.1. Необходимо знать язык SQL и основные принципы RDBMS как транзакции, foreign key, таблицы.
Допустим вы разработчик Java, и от вас еще требуют знать какой-то SQL и особенности RDBMS. Естественно вы ленитесь, пытаетесь как-то отвильнуть.
Да и к тому-же принцип ООП очень не похож на модель данных в RDBMS.
1.2. Если у вас большой проект, то вам нужен профессиональный БД разработчик, а это лишний балласт если не будет проектов в будущем.
Java программистам так и хочется сделать всю бизнес логику на Java в обход SQL и RDBMS.
Второе, Цена
2.1. Невозможность использовать commodity сервера на больших данных. Если у вас 600 Терабайт, то вам из RDBMS подойдет только Exadata или Teradata.
2.2. Отказоустойчивость. Без технологии shared-nothing и no single point failer вы вынуждены покупать дорогие сервера, с двойным резервированием всего,
RAID контроллеров, блоков питания, покупать бесперебойник, дорогие хранилки и так далее.
2.3. Цена лицензий. RDBMS с развитыми возможностями, способные держать сотни терабайт не дешево, особенно appliance решения.
Третье, >=1 Pb данных
3.1. Если у вас больше 1 Петабайт данных, то вам из RDBMS подходит уже только Терадата за 20 млн.$
Тогда как собрать кластер для Hadoop с тройной избыточностью на 1 Петабайт данных сейчас стоит 367 000$ (только сервера с дисками).
На вот таких вот серверах и 4 дисках в RAID 0
www.ulmart.ru/goods/613438
www.ulmart.ru/goods/690535
Правда на электроэнергии разоритесь. Для такого детища потребуется мини электростанция.
Вот собственно по этому и началось это движение NoSQL, Hadoop, MPP. Для решения вышеизложенных особенностей, неудобств, недостатков.
Вывод:
RDBMS по прежнему остаются универсальными БД способными ��ешить любые задачи. Так что советую лишний раз подумать, является ли один из вышеизложенных пунктов для вас критичным. Если нет, то смело берите обычную RDBMS!
Вердикт:
1. Если у вас денег куры не клюют, у вас сложная разработка или нужно неблокирующее чтение и вы любите комфортные условия разработки.
Покупайте Exadata
2. Если у вас денег куры не клюют, не очень сложная разработка, вас не пугает отсутствие хорошего инструментария,
и вы не любите создавать агрегаты, а любите грубую силу full scan то покупайте Терадату
3. Если у вас есть деньги, но вы умеете их считать, вам нужна стабильная, универсальная и простая в разработке БД и данных у вас меньше 10 Терабайт, и вас не пугает сложность администрирование, то берите обычный Oracle
4. Если у вас нет денег, но данных не больше 1 Тб, но вам по прежнему нужна хорошая платформа для разработки БД со сложной логикой, то берите PostgreSQL
5. Если у вас нет навыков SQL и RDBMS, данные слабо-связанные или у вас хороший ETL, который все отлавливает. Не сложные запросы без соединения множества таблиц. Вся логика не в БД. То вам вполне подойдет NoSQL БД, хотя, как я и сказал, RDBMS универсальны, могут все что угодно, если вы умеете ими пользоваться.
