Stock - где что почем?

[avitya]

Я, простихоспади, в последний раз настоящий SQL запрос ещё в амазоне писал, почти четыре года назад.

[dotcom]

Почему не наоборот? Например: зачем нужен оракл если он загибается на 10k QPS

Оракл обидеть большого ума не надо.

[Albert_al]

это вопросы по SQL которые вы задаете java программисту?

Нет, это вопросы укровища(DWH) данных девелоперу или типа database инженегру

[Krys-Krys]

У меня на проекте БД тоже нет особо (только для 1й страницы искать диллеров по зип коду там ровно 3 запроса в базу).
Пользуем Java Content Repository API.

[mynameiszb]

Почему не наоборот? Например: зачем нужен оракл если он загибается на 10k QPS

Оракл обидеть большого ума не надо.

Как вы только этого добиваетесь? Толпа клиентов, каждый в среднем шарашит около тех самых 10 тысяч в секунду. На пиковых нагрузках и того больше. И хоть бы треснуло где... А еще поверх этого переброс накопленных данных для последующей обработки в DWH, ну и другие задачи, которые попутно живут в других схемах...

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

[crypto5]

А что же вы архитектора на ковер вызывали, и еще наверное программеров напрягали если все работает?

[mynameiszb]

А что же вы архитектора на ковер вызывали, и еще наверное программеров напрягали если все работает?

Оно работает после того, как руки.sys поправили. Но если систему через одно забавное место организовать, то можно любые ресурсы сожрать. Главное - голову не подключать, а ручки сами отчебучат

[valchkou]

Оно работает после того, как руки.sys поправили. Но если систему через одно забавное место организовать, то можно любые ресурсы сожрать. Главное - голову не подключать, а ручки сами отчебучат

но ты согласен, что косяки на архитекторе, а не на java программистах, которые не знают "How to move a very big table from one DB to another" ?

[mynameiszb]

но ты согласен, что косяки на архитекторе, а не на java программистах, которые не знают "How to move a very big table from one DB to another" ?

Я думаю, что программисты должны получить нечто специфицированное: как читать, как писать, куда гвозди заколачивать. А вот почему архитект при работе с базой не проконсультировался с админами - это для меня загадка.
Ну и когда такие косяки закладывают еще на моменте проектирования, потом достаточно сложно систему привести в работоспособное состояние.

[valchkou]

Я думаю, что программисты должны получить нечто специфицированное: как читать, как писать, куда гвозди заколачивать.

верно, для этих целей уже встроены стандартные best practices в стандартные фреймворки типа hibernate.
и любой себя уважающий жава архитект должен знать о них. И рассказать об этом программистам, что рекомендуется использовать, а что нет.

Просто изначально был наезд на java программистов от альберта, а затем и от тебя, что пишут код не понимая потрохов ДБ оракл. А зачем понимать если есть архитект и админ, вот пусть они поймут и расскажут.
Но почему то почти нигде такое не практикуется, все только жмутся по своим углам со своими сокровенными знаниями, а потом ворчат, что у всех руки кривые.

Не в пример в москве, когда я в сибосе работал, как раз проводили лигбез по ораклу среди программистов.
Целая дока была админами написана про то как писать запросы, как понимать трейсы, . В добавок были лекции.
А если админ отлавливал кривой план, то прог сразу об этом знал и бежал править в первую очередь. (ADD admin driven development)

[Albert_al]

[Просто изначально был наезд на java программистов от альберта

Да это не наезд, просто ответ Крысе на слова что база и SQL - это все жутко просто
Работал я с Сбоссом в машинно-тракторной станции, тренинг проходил по ходу работы

[mynameiszb]

и любой себя уважающий жава архитект должен знать о них. И рассказать об этом программистам, что рекомендуется использовать, а что нет.

Очень хорошие слова. Беда лишь в том, что зачастую архитект это до программистов не доносит. И сами программисты редко горят желанием изучать "еще эти потроха, когда у меня план по валу горит"...

В Дойче любой новый модуль обсуждали с привлечением dba. Потому что работали с базой активно. И админ советовал, на основании требований, как лучше организовать хранение и выборку данных в базе. Плюс - все запросы проходили верификацию у него же, не считая тестов и нагрузочных, которые отдельно выполнялись. Зато и запросы удавалось отработать до хорошей скорости еще до момента запуски в production.

[crypto5]

А что же вы архитектора на ковер вызывали, и еще наверное программеров напрягали если все работает?

Оно работает после того, как руки.sys поправили. Но если систему через одно забавное место организовать, то можно любые ресурсы сожрать. Главное - голову не подключать, а ручки сами отчебучат

Ну вот видите, а большинству NoSql решений 10k qps даже на дешевом боксе это укус мухой слона

[Easbayguy]

А что же вы архитектора на ковер вызывали, и еще наверное программеров напрягали если все работает?

Оно работает после того, как руки.sys поправили. Но если систему через одно забавное место организовать, то можно любые ресурсы сожрать. Главное - голову не подключать, а ручки сами отчебучат

Ну вот видите, а большинству NoSql решений 10k qps даже на дешевом боксе это укус мухой слона

Ааа мистические 10qps, при условии чтобы все данные были в памяти и как в монге, w=1 и не писать коммит логи на диск.

[crypto5]

А что же вы архитектора на ковер вызывали, и еще наверное программеров напрягали если все работает?

Оно работает после того, как руки.sys поправили. Но если систему через одно забавное место организовать, то можно любые ресурсы сожрать. Главное - голову не подключать, а ручки сами отчебучат

Ну вот видите, а большинству NoSql решений 10k qps даже на дешевом боксе это укус мухой слона

Ааа мистические 10qps, при условии чтобы все данные были в памяти и как в монге, w=1 и не писать коммит логи на диск.

Ну например кассандра отлично ест обсуждаемые 10k inserts/updates даже если все не помещается в памяти, в силу своих архитектурных решений, то же самое hbase например.
А монго это странная база, я ее защищать не берусь

[Easbayguy]

Ну например кассандра отлично ест обсуждаемые 10k inserts/updates даже если все не помещается в памяти, в силу своих архитектурных решений, то же самое hbase например.
А монго это странная база, я ее защищать не берусь

Да ест первые 10K insert/updates, а на 3ем терабайте начинаются затыки с compact/repair, колличество записей в табличке приходится смотреть в статистике, потому что "select count" сваливается на timeout. Записи которые часто изменяются ставят в затык саму табличку, которую потом невозможно не пофиксит/не пересоздать и приходится удалять физически файлы/директории на всех нодах и перестартовывать. Там много веселого, когда начинаешь сопровождать.

[Krys-Krys]

[Просто изначально был наезд на java программистов от альберта

Да это не наезд, просто ответ Крысе на слова что база и SQL - это все жутко просто

Для джава девелопера который работает с хибернейтом и пищет другого рода SQL запросы на выборку, вставку и проч - не должно быть ничего сложного. Достаточно знать об индексах, batch, пуле и иже с ним это все замечательно делается в самой Java (кроме индексов) - тот же голый JDBC который нынче уже не в моде ну просто и batch замутит, и пул коннекшенов можно там же организовать и транзакции, д и т п. Если требуют намного больше - пусть наймут еще одного человека, специалиста по базе - не знаю уж кого, админа, девелопера, архитектора, и он пуская посматривает и советы дает. Я так понимаю.

[crypto5]

Ну например кассандра отлично ест обсуждаемые 10k inserts/updates даже если все не помещается в памяти, в силу своих архитектурных решений, то же самое hbase например.
А монго это странная база, я ее защищать не берусь

Да ест первые 10K insert/updates, а на 3ем терабайте начинаются затыки с compact/repair, колличество записей в табличке приходится смотреть в статистике, потому что "select count" сваливается на timeout. Записи которые часто изменяются ставят в затык саму табличку, которую потом невозможно не пофиксит/не пересоздать и приходится удалять физически файлы/директории на всех нодах и перестартовывать. Там много веселого, когда начинаешь сопровождать.

Ну если держать по 3 террабайта на одном ноде, то наверное да, так и будет

[mynameiszb]

Да ест первые 10K insert/updates, а на 3ем терабайте начинаются затыки с compact/repair, колличество записей в табличке приходится смотреть в статистике, потому что "select count" сваливается на timeout. Записи которые часто изменяются ставят в затык саму табличку, которую потом невозможно не пофиксит/не пересоздать и приходится удалять физически файлы/директории на всех нодах и перестартовывать. Там много веселого, когда начинаешь сопровождать.

Ну если держать по 3 террабайта на одном ноде, то наверное да, так и будет

Не знаю про NoSQL, но под ораклом мы сидели в 7-10ТБ и не жужжали. В смысле - оно писало, одновременно с этим читало, плюс еще данные ковыряло в других схемах. Табличные были разнесены, чтобы друг другу не мешать, но все бегало.

Мое большое imho: если у человека понимание технологий есть и он умеет их использовать, то из выданного инструментария можно выжать очень многое. А если он лишь "от забора..." - то сломает любые супер-пупер решения

[crypto5]

Да ест первые 10K insert/updates, а на 3ем терабайте начинаются затыки с compact/repair, колличество записей в табличке приходится смотреть в статистике, потому что "select count" сваливается на timeout. Записи которые часто изменяются ставят в затык саму табличку, которую потом невозможно не пофиксит/не пересоздать и приходится удалять физически файлы/директории на всех нодах и перестартовывать. Там много веселого, когда начинаешь сопровождать.

Ну если держать по 3 террабайта на одном ноде, то наверное да, так и будет

Не знаю про NoSQL, но под ораклом мы сидели в 7-10ТБ и не жужжали. В смысле - оно писало, одновременно с этим читало, плюс еще данные ковыряло в других схемах. Табличные были разнесены, чтобы друг другу не мешать, но все бегало.

Мое большое imho: если у человека понимание технологий есть и он умеет их использовать, то из выданного инструментария можно выжать очень многое. А если он лишь "от забора..." - то сломает любые супер-пупер решения

На кассандре в кластере вполне и сотни террабайт держат, речь шла об одном ноде, вот на проекте где я главный у нас не кассандра, но наш NoSql вполне 70ТБ компрессированную базу держит, которую мы полностью перезаписываем раз в пять дней, и QPS там больше 10к

[mynameiszb]

На кассандре в кластере вполне и сотни террабайт держат, речь шла об одном ноде, вот на проекте где я главный у нас не кассандра, но наш NoSql вполне 70ТБ компрессированную базу держит, которую мы полностью перезаписываем раз в пять дней, и QPS там больше 10к

Я про одну ноду и говорю.
Вы расскажите - аналитические запросы одновременно с активной записью по этой же базе можно делать? Я слышал, что кассандра не любит, когда при записи попутно еще эти же данные читать пытаются.

PS. Я в NoSQL - полный дундук, поэтому можно простыми словами

[crypto5]

На кассандре в кластере вполне и сотни террабайт держат, речь шла об одном ноде, вот на проекте где я главный у нас не кассандра, но наш NoSql вполне 70ТБ компрессированную базу держит, которую мы полностью перезаписываем раз в пять дней, и QPS там больше 10к

Я про одну ноду и говорю.

У вас тоже ноды спрятаны в ваш SAN/NAS, или у вас мейнфрейм какой за 10 миллионов.

Вы расскажите - аналитические запросы одновременно с активной записью по этой же базе можно делать? Я слышал, что кассандра не любит, когда при записи попутно еще эти же данные читать пытаются.

PS. Я в NoSQL - полный дундук, поэтому можно простыми словами

В кассандре нету аналитических запросов, я так понимаю стандартный способ это прикручивать к ней хадуп, и на нем сложную аналитику считать. Любит/не любит понятно зависит от конкретных кейсов.

[Easbayguy]

Ну например кассандра отлично ест обсуждаемые 10k inserts/updates даже если все не помещается в памяти, в силу своих архитектурных решений, то же самое hbase например.
А монго это странная база, я ее защищать не берусь

Да ест первые 10K insert/updates, а на 3ем терабайте начинаются затыки с compact/repair, колличество записей в табличке приходится смотреть в статистике, потому что "select count" сваливается на timeout. Записи которые часто изменяются ставят в затык саму табличку, которую потом невозможно не пофиксит/не пересоздать и приходится удалять физически файлы/директории на всех нодах и перестартовывать. Там много веселого, когда начинаешь сопровождать.

Ну если держать по 3 террабайта на одном ноде, то наверное да, так и будет

Ну давайте посмотрим: 10k inserts/sec x 3600*24 = 864,000,000 records per day, average size 500bytes.
Для простоты 400ГБ в день. 5 node cluster, 3 replicas. Итого 240ГБ на машину в день, 3 ТБ через 10 дней. Если предположить что ночью народ не работает, то через 20 дней.
То есть вы либо должны не хранить такие данные в кассандре, либо удалять их раз в месяц.

[crypto5]

Ну например кассандра отлично ест обсуждаемые 10k inserts/updates даже если все не помещается в памяти, в силу своих архитектурных решений, то же самое hbase например.
А монго это странная база, я ее защищать не берусь

Да ест первые 10K insert/updates, а на 3ем терабайте начинаются затыки с compact/repair, колличество записей в табличке приходится смотреть в статистике, потому что "select count" сваливается на timeout. Записи которые часто изменяются ставят в затык саму табличку, которую потом невозможно не пофиксит/не пересоздать и приходится удалять физически файлы/директории на всех нодах и перестартовывать. Там много веселого, когда начинаешь сопровождать.

Ну если держать по 3 террабайта на одном ноде, то наверное да, так и будет

Ну давайте посмотрим: 10k inserts/sec x 3600*24 = 864,000,000 records per day, average size 500bytes.
Для простоты 400ГБ в день. 5 node cluster, 3 replicas. Итого 240ГБ на машину в день, 3 ТБ через 10 дней. Если предположить что ночью народ не работает, то через 20 дней.
То есть вы либо должны не хранить такие данные в кассандре, либо удалять их раз в месяц.

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

[Easbayguy]

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

С моей точки зрения, NoSQL хорош для хранения временных/нестурктурированных данных которые не требуют backup и не предполагают ананлитической обработки внутри базы. Которому не нужен контроль транзакций и как вы о своем приложении, перезаписывается каждые 5 дней, веб логи и так далее.