Часовой пояс: UTC + 3 часа




Начать новую тему Новая тема / Ответить на тему Ответить  Сообщений: 15 
  Пред. тема | След. тема 
Автор Сообщение
 

роБОТяга
Статус: Не в сети
Регистрация: 05.07.2005
Ждём Ваших отзывов о материале.

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

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

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



Партнер
 

Member
Статус: Не в сети
Регистрация: 28.04.2012
Откуда: Невинномысск
Вопрос в том будут ли эту СУБД приобретать корпоративные клиенты, если есть и не очень удобный, но бесплатный MySQL?

_________________
i5-4670k, Gigabyte Z87X-D3H, Corsair VengeanceLP 2*4Gb 1866MHz, Noctua NH-D14, Corsair Carbide Series 500R, Corsair HX650.


 

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

_________________
Однополярный мир умер и воскрешению не подлежит (70 сессия Генеральной Ассамблеи ООН)


 

Member
Предупреждение 
Статус: Не в сети
Регистрация: 05.08.2011
Откуда: Новополоцк
Crow26 писал(а):
Вопрос в том будут ли эту СУБД приобретать корпоративные клиенты, если есть и не очень удобный, но бесплатный MySQL?

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

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


 

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

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


 

Member
Статус: Не в сети
Регистрация: 26.12.2009
Откуда: Самара
Цитата:
Аналитик IDC Аль Гиллен заявил, что Microsoft остаётся приверженцем кроссплатформенных решений

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

_________________
P4 1500->Sempron 3000+->Athlon 64 X2 4000+->T4200->4670k


 

Member
Статус: Не в сети
Регистрация: 29.07.2015
Откуда: МОСКВА
Фото: 2
directx под линукс случайно не ожидается? :D


 

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


 

Member
Статус: Не в сети
Регистрация: 10.06.2012
Откуда: Норильск
Фото: 1
Civilian писал(а):
Вы просто не умеете его готовить (c). MySQL при наличии нормальных специалистов в команде вполне может ворочать базами на сотни гигов.

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

_________________
3770K / GTX1070 / 16Gb RAM


 

Junior
Статус: Не в сети
Регистрация: 25.11.2015
Откуда: Amsterdam
Mause писал(а):
У нас одна не очень большая таблица весит 24+Гб и это просто одна из сотен таблиц, с которыми работают более 4000 пользователей, боюсь MySQL загнётся от такого наплыва примерно... сразу, там выборка по простому ключу из миллиона записей уже на более чем 1сек затянется

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

Цитата:
там выборка по простому ключу из миллиона записей уже на более чем 1сек затянется

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


 

member+
Статус: Не в сети
Регистрация: 16.01.2004
Откуда: Estonia,Tallinn
Mause писал(а):
У нас одна не очень большая таблица весит 24+Гб и это просто одна из сотен таблиц

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

_________________
Так что я одним зайцем два камня убиваю ©


 

Member
Статус: Не в сети
Регистрация: 10.06.2012
Откуда: Норильск
Фото: 1
Vladson писал(а):
Не знаю где вы работаете, но мне кажется что у вас и правда проблема. Только проблема не в том что MySQL не потянет, а в том что ваша архитектура придумана идиотами которые ничего в оптимизации не смыслят...

:lol: в каком месте проблема?))) в том что это просто список документов, участвующих в документообороте?))) ГМК НН, система SAP, это даже стандарт, а не собственные таблицы :lol:
Civilian писал(а):
Еще раз повторю, что нужно просто уметь его готовить. Сотни гигов это боевые базы, с которыми работают люди, притом не самые большие, просто так сказать то, что есть на текущей работе. Из самого большого что видел - в одной из предыдущих компаний был MySQL

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

_________________
3770K / GTX1070 / 16Gb RAM


 

Junior
Статус: Не в сети
Регистрация: 25.11.2015
Откуда: Amsterdam
Mause писал(а):
Поймите, что это не штатная работа для такой СУБД. Можно и колесо квадратным сделать и ехать заставить, и оно поедет, вот только круглое всё же будет лучше для этой цели подойдёт. Также и с MySQL, можно, но это приделывание костылей к велосипеду

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


 

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

_________________
3770K / GTX1070 / 16Gb RAM


 

Junior
Статус: Не в сети
Регистрация: 25.11.2015
Откуда: Amsterdam
Mause писал(а):
вот именно в том то и дело, что MySQL не сможет ворочить такими базами также легко как MSSQL или Oracle.

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

Цитата:
Эм... вы в одну строчку поставили SAP и 1C )) жестко))) 1Ску вы скорее всего видели и я полностью согласен что это жуткое тормозящее УГ, но вот на SAP зря вы наговариваете, скорость работы на уровне СУБД

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

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


Показать сообщения за:  Поле сортировки  
Начать новую тему Новая тема / Ответить на тему Ответить  Сообщений: 15 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: jugador и гости: 14


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Перейти:  
Get Adobe Flash player





Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB | Kolobok smiles © Aiwan


Яндекс.Метрика