Ждём Ваших отзывов о материале.

Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
За статью можно проголосовать на странице материала.

Напоминаем о том, что на сообщения новых участников распространяется действие системы премодерации сообщений.

О нарушениях можно сообщить модератору, нажав синюю кнопку #77 справа над спорным сообщением.

Вопрос в том будут ли эту СУБД приобретать корпоративные клиенты, если есть и не очень удобный, но бесплатный MySQL?

Crow26, Во первых в корпоративной среде не в сервере дело, он там вторичен после системы автоматизации.
Во вторых, MySQL уж слишком дохлый для сравнения. Он больше для мелких и не сложных запросов. Хотя бы postgre

Смешно, вы вообще с ним работали? Запрос в таблицу из миллиона записей будет вечность обрабатываться, а не дай бог еще связи какие запилить. MySQL это уровень максимум небольшого местного магазинчика/сервиса (короче для малого бизнеса).

MS SQL же потеснит Oracle DB и это очень и очень хорошо, ибо конкуренция силас.

Вы просто не умеете его готовить (c). MySQL при наличии нормальных специалистов в команде вполне может ворочать базами на сотни гигов. Чтобы не быть голословным, пример крупной конторки которая активно использует сложный мускуль - букинг (см их технический блог на предмет статей, там же есть и указания на примерные размеры).

Ждем телеметрию под Linux

directx под линукс случайно не ожидается?

Я думаю они со своей дотнет платформой долго думали - лет 15, ещё изначально нужно было делать кроссплатформенную по примеру JVM, ведь именно на конкуренцию с Явой оно и рассчитано. Если они ещё под линукс запилят толковую поддержку .Net, сделают туда свою студию, офис, ещё и винду хоум эдишн вобще бесплатной сделают - вот где скрытый потенциал для роста и разрабы под линуксом оценят.

Эм, нет, ну серьёзно. "сотни гигов" - это может быть и много для MySQL, даже если они там и мёртвым грузом лежат, для MySQL или Oracle это раз плюнуть. У нас одна не очень большая таблица весит 24+Гб и это просто одна из сотен таблиц, с которыми работают более 4000 пользователей, боюсь MySQL загнётся от такого наплыва примерно... сразу, там выборка по простому ключу из миллиона записей уже на более чем 1сек затянется

Еще раз повторю, что нужно просто уметь его готовить. Сотни гигов это боевые базы, с которыми работают люди, притом не самые большие, просто так сказать то, что есть на текущей работе. Из самого большого что видел - в одной из предыдущих компаний был MySQL (пачка серверов, шардированная, master-slave пары), в который очень активно ходили пользователи (т.к. там хранились данные для аналитики для клиентов) - т.е. на каждый шард приходили десятки пользовательских запросов в секунду на чтение последних данных, иногда были запросы на чтение исторических данных и при этом постоянно шли обновления. Размер базы на 1 сервер достигал 1.5ТБ. Работало достаточно вменяемо, проблемы были связанные с тем как работает репликация в MySQL 5.1 (на тот момент было последним стабильным релизом) и с тем, что на адекватную работу такой штуки нужно было держать у каждого сервера полки (иногда более 1) с SAS дисками по 300ГБ в рейде10 (SSD не было, 600ГБ SAS диски было достать сложно, SATA дисков не хватало по IOPS'ам).


Это лишь значит, что DBA неправильно сконфигурировал базу, не более того.

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

в каком месте проблема?))) в том что это просто список документов, участвующих в документообороте?))) ГМК НН, система SAP, это даже стандарт, а не собственные таблицы

Поймите, что это не штатная работа для такой СУБД. Можно и колесо квадратным сделать и ехать заставить, и оно поедет, вот только круглое всё же будет лучше для этой цели подойдёт. Также и с MySQL, можно, но это приделывание костылей к велосипеду

Не штатная - если бы приходилось городить костыли и подпорки. В данном случаи масштабирование до ТБых баз требовало лишь вменяемого железа (даже не топового) и быстрых дисков. Это вполне штатное поведение нормально спроектированной системы. Ах да, т.к. это общался с этим внутренний софт, он тоже был написан с рассчетом на MySQL. Как это ни странно, но у каждой БД свои особенности работы которые нужно учитывать при составлении запросов и построении схем. Это кстати одна из главных причин почему всякие 1Сы и SAPы хорошо себя чувствуют с одной базой данных с расчетом на которую они и писались. Вторая причина в том, что сами системы написаны не очень то эффективно (цели написать эффективный код, оптимизировать запросы и т.п. при разработке 1Сов и SAPов не ставились никогда). Так что Vladson прав, проблема в том как разрабатываются эти системы.

Civilian, вот именно в том то и дело, что MySQL не сможет ворочить такими базами также легко как MSSQL или Oracle. Я даже могу согласиться в том, что при малых объёмах MySQL будет быстрее MSSQL (с Oracle спорно из-за одной фишечки оракла), но с увеличением нагрузки до миллионов - MySQL безбожно сольётся в производительности, её удел - маленькие базы, либо сильно распределённые, что уже костыли.
Эм... вы в одну строчку поставили SAP и 1C )) жестко))) 1Ску вы скорее всего видели и я полностью согласен что это жуткое тормозящее УГ, но вот на SAP зря вы наговариваете, скорость работы на уровне СУБД

Опять же, выше примеры, MySQL хорошо ими ворочал. Возможно конечно не так хорошо как это бы делал оракл, но при этом цена оракла на такие масштабы перекрывала любые выгоды от скорости - проще было поставить еще 50 серваков и попилить базы, чем платить за лицензии (не говоря о том, что MySQL DBA в штате уже есть, а оракловых надо искать, нанимать, а это месяцы).


Что совершенно не мешает тому, что он может использовать СУБД совершенно неэффективно. А он вероятно это и делает, потому что что SAP что 1С это в первую очередь конструкторы для приложений по управлению процессами, а универсальность не бывает бесплатной, никогда. И к счастью я не имею дел ни с 1С ни с SAP, только доходят жалобы на них от других коллег.

P.S. И Вы еще не забывайте, что нельзя просто взять и поменять базу данных, без каких либо последствий. Хочешь выжать из базы максимум - оптимизируй запросы и структуры данных под нее и ровно поэтому когда у приложения заявлена поддержка MS SQL, Oracle, DB2, MySQL, Postgre - работать адекватно оно будет только на одной из них, притом только на той под которую делалась оптимизация.