а вот интересно возможно ли перекинуть ibdataX на другой раздел без остановки сервиса на Server version: 5.6?

ребята, а есть тут кто настраивал импорт в Elastic через Logstash? все доки перерыл, parent-child ассоциации не хотят работать

вручную работает на ура

да, маппинг настроен

фишка в том, что _parent поле сетится, но поиск не происходит по асссоциации

когда делаю вручную - все работает, мистика

бывает же...

Всем привет, моежете проконсультировать с выбором БД? Сейчас на проекте MS SQL, но постепенно он перестает нас устраивать. Ищем БД, способную в группировки над группировками над группировками, для работы с миллионами денормализованными сущностями и, соответственно, важна быстрая выборка данных и возможность данные обновлять. Сейчас собираемся тестировать монгу и clickhouse, но там пока что свои вопросы.

Всем привет, моежете проконсультировать с выбором БД? Сейчас на проекте MS SQL, но постепенно он перестает нас устраивать. Ищем БД, способную в группировки над группировками над группировками, для работы с миллионами денормализованными сущностями и, соответственно, важна быстрая выборка данных и возможность данные обновлять. Сейчас собираемся тестировать монгу и clickhouse, но там пока что свои вопросы.

И чем не устраивает ?

"Ищем БД, способную в группировки над группировками над группировками, для работы с миллионами денормализованными сущностями и, соответственно, важна быстрая выборка данных и возможность данные обновлять" MS SQL на всё это способен.

И чем не устраивает ?

Тем, что MS SQL начинает умирать на наших нагрузках

Если вам кажется, что нет, это вопрос скорее к вам, чем к этой замечательной СУБД (без сарказма)

А какая версия?

Тем, что MS SQL начинает умирать на наших нагрузках

Значит, не умеете готовить.

Тем, что MS SQL начинает умирать на наших нагрузках

Сколько и каких серверов? Сколько данных и как джойнити? Что с НФ по данным? Смотрели в сторону SSAS?

Всем привет, моежете проконсультировать с выбором БД? Сейчас на проекте MS SQL, но постепенно он перестает нас устраивать. Ищем БД, способную в группировки над группировками над группировками, для работы с миллионами денормализованными сущностями и, соответственно, важна быстрая выборка данных и возможность данные обновлять. Сейчас собираемся тестировать монгу и clickhouse, но там пока что свои вопросы.

В любом случае, что можно посоветовать людям, которые не могут обработать данные на очень хорошей СУБД? Стоит ли им что-то вообще советовать ? Они не смогут данные обработать и на любой другой СУБД,

Я не спорю, что может, и не отрицаю того, что мс сиквел прекрасен, я говорю о том, что текущую нагрузку он не выдерживает => собираемся переписывать инфраструктуру

Какие нагрузки?

Сколько и каких серверов? Сколько данных и как джойнити? Что с НФ по данным? Смотрели в сторону SSAS?

это вопросы к админам уже, я разраб)

Я не спорю, что может, и не отрицаю того, что мс сиквел прекрасен, я говорю о том, что текущую нагрузку он не выдерживает => собираемся переписывать инфраструктуру

Лучше наймите хорошего специалиста по БД

это вопросы к админам уже, я разраб)

У меня тогда один вопрос, а почему вы принимаете решение о смене БД?

это вопросы к админам уже, я разраб)

Ну вот видишь... ТЫ плохой разраб, если этого не знаешь.

Пускай придет человек, ответственный за БД и задаст свои вопросы и ответит на наши

А пока все это выглядит, мягко говоря, что вы полезли не туда и не умеете работать с БД от слова "совсем"

@vitaminniy , как бы чтобы советовать что-то при выборе СУБД, надо очень хорошо знать задачу и её нагрузку на СУБД. БЕз этого все советы будут — пустой пшик, личные предпочтения советующего.

момент, спасибо, сейчас позову

Так что твой вопрос бессмысленный

MS SQL не устраивает нас тем, что не масштабируется и не позволяет хранить массивы.

у вас есть ответственный за БД? или только разрабы и админы/девопсы?

есть DBA

отлично, вот пускай он придет и задаст вопросы

но он немного в ауте, его круг задач связан с другими проектами

ааа, ну логично, ДБА занят в другом проекте, поэтому в этом поменяем БД без ДБА

огонь ага

?

В общем, дам только один совет, либо ждите ДБА, либо забудьте про ДБА совсем - третьего не дано

Всем привет, моежете проконсультировать с выбором БД? Сейчас на проекте MS SQL, но постепенно он перестает нас устраивать. Ищем БД, способную в группировки над группировками над группировками, для работы с миллионами денормализованными сущностями и, соответственно, важна быстрая выборка данных и возможность данные обновлять. Сейчас собираемся тестировать монгу и clickhouse, но там пока что свои вопросы.

Ну возможно под такое пойдут columnstore СУБД типа Vertica, Virtuoso, но вот с ОБНОВЛЕНИЕМ данных там всё ПЛОХО.

Ну и миллионы — это для них очень мало.

сейчас окажется, что агрегации должны что-нибудь атомарно обновлять

Ну возможно под такое пойдут columnstore СУБД типа Vertica, Virtuoso, но вот с ОБНОВЛЕНИЕМ данных там всё ПЛОХО.

В вертике кстати стало очень не плохо обновление, просто надо уметь готовить запросы...

MS SQL не устраивает нас тем, что не масштабируется и не позволяет хранить массивы.

На кой тебе в РЕЛЯЦИОННОЙ СУБД массивы ?

я думаю им нужны массивы в БД, потому что они программисты

дермолизация базы

=)

На кой тебе в РЕЛЯЦИОННОЙ СУБД массивы ?

Тем более, что MSSQL УМЕЕТ массивы

Ни у кого случайно нет стикера рукожопа ?

На кой тебе в РЕЛЯЦИОННОЙ СУБД массивы ?

в реляционной - ни на кой, новые требования, все дела

чет DBA задерживается )

ДБА сбежал на другой проект

в реляционной - ни на кой, новые требования, все дела

мне просто интересно, что за новые требования, которые массивы не могут положить в таблицу?

от ужоса )

мне просто интересно, что за новые требования, которые массивы не могут положить в таблицу?

2к17 ?

на самом деле есть кейсы где массивы полезны

Есть, конечно. Так пусть ОН объяснит...

или один ДБА на все проекты. зачем больше-то?

ну хватит уже, про columnstore СУБД сейчас тогда почитаю, спасибо

не зайдут вам они скорее всего, ибо агрегаты в агрегатах погоняют

ну хватит уже, про columnstore СУБД сейчас тогда почитаю, спасибо

Вот тебе сходу целая статья про массивы в SQLServer https://www.red-gate.com/simple-talk/sql/t-sql-programming/faking-arrays-in-transact-sql/

не зайдут вам они скорее всего, ибо агрегаты в агрегатах погоняют

поясни

ну, мы часть данных в ластике храним и даже думали его использовать, но там нет возможности группироваться по группировакм и прочие сложные вычисления делать

поясни

что КХ, что Вертика (за другие не ручаюсь), просто нельзя писать запросы, в которых агрегаты в агрегатах погоняют... Точнее можно, но с множеством НО и готов поспорить на месячную ЗП Максима, что они упрутся в эти условия и лимиты

ну, мы часть данных в ластике храним и даже думали его использовать, но там нет возможности группироваться по группировакм и прочие сложные вычисления делать

Потому что Elastic — это не СУБД...

что КХ, что Вертика (за другие не ручаюсь), просто нельзя писать запросы, в которых агрегаты в агрегатах погоняют... Точнее можно, но с множеством НО и готов поспорить на месячную ЗП Максима, что они упрутся в эти условия и лимиты

КХ что?

КХ что?

кликхаус

Да ну, это вообще несерьёзно

а в КХ это не имеет смысла, там же звезда с внешними справочниками, в рамках звезды все ОК, а в сторону уйти - это будет большая боль для них

ну хватит уже, про columnstore СУБД сейчас тогда почитаю, спасибо

и про SQLite, мечту разработчика

что КХ, что Вертика (за другие не ручаюсь), просто нельзя писать запросы, в которых агрегаты в агрегатах погоняют... Точнее можно, но с множеством НО и готов поспорить на месячную ЗП Максима, что они упрутся в эти условия и лимиты

А так надо 0) СМОТРЕТЬ НА ИХ ЗАПРОСЫ, 1) использовать CTE или подзапросы во FROM/ Если этого нет, в Vertica, то да, блин... Ну я точно не помню, были там какие-то ограничения, помню. какие — не помню. Запросы у нас были вполне себе дурацкие простецкие

А так надо 0) СМОТРЕТЬ НА ИХ ЗАПРОСЫ, 1) использовать CTE или подзапросы во FROM/ Если этого нет, в Vertica, то да, блин... Ну я точно не помню, были там какие-то ограничения, помню. какие — не помню. Запросы у нас были вполне себе дурацкие простецкие

Ты не понял, они хотят агрегаты в агрегатах и дальше по рекурсии

такое в БД писать одна сплошная боль по определению

Ты не понял, они хотят агрегаты в агрегатах и дальше по рекурсии

Ну, эта рекурсия не может быть бесконечной

А так надо смотреть.

Им бы данные лучше структурировать и нормализовать, оптимизировать хранение и запросы и возможно разделить чтение/запись

Им бы данные лучше структурировать и нормализовать, оптимизировать хранение и запросы и возможно разделить чтение/запись

Ну так тоже нельзя, мы ж не видали их...

про что и речь\

Ну так тоже нельзя, мы ж не видали их...

+

Но упомянутая ДЕнормализация — да, это путь в никуда...

может там вообще таблицы с одними индексами на pk и джойны по varchar'ам

Это самый глупый ход, что можно придумать

Всё, я ушёл

конкретно сейчас мы храним, в основном, числовые и битовые поля, + пара варчаров, ну и составные pk. Новая БД у нас, как минимум, повлечет за собой смену структуру этих данных, потому и спрашивал: есть ли что-то, изначально направленное на хранение большого количества данных и работу с этими объемами

что в вашем понимании "большой объем данных"?

А MSSQL тебе чем не нравица ? Он на это РАСЧИТАН.

Миллионы — это не очень и большие объёмы

у меня был проект на MS SQL 2005, где в таблице под сотню лямов записей нужные агрегаты считались за секунду

размер индекса эластика за день составляет порядка 1тб, даже учитывая, что эти данные мы потом обрабатываем и прочее - сколько это занимает в ms sql после записи - не знаю

при этом сервер был слабже, чем сейчас макбуки ?