Частая смена работы становится нормой?

[nightmare2]

Я вот кстати думаю куда податься будучи Senior Oracle DBA / Senior Oracle developer с 14-ю годами опыта в каждой из областей ? В Architect ?

Dedicated Database Architect?
Они еще кому-то нужны?

[Stoic]

Да и вообще, если последние 14 лет только Оракл был, и ничего кроме него, то надо сидеть на попе очень очень ровно.

[Alexandr]

Да и вообще, если последние 14 лет только Оракл был, и ничего кроме него, то надо сидеть на попе очень очень ровно.

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

[Easbayguy]

Да и вообще, если последние 14 лет только Оракл был, и ничего кроме него, то надо сидеть на попе очень очень ровно.

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

Не в Сан Франциско работаете?

[valchkou]

самое время прыгать в поезд NoSql, BigData инженеров.
там и архитекты и ДБ админы и ДБ модельеры требуются.

[Alexandr]

Да и вообще, если последние 14 лет только Оракл был, и ничего кроме него, то надо сидеть на попе очень очень ровно.

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

Не в Сан Франциско работаете?

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

[Леонид Ильич Брежнев]

самое время прыгать в поезд NoSql, BigData инженеров.

Опомнился.
Туда прыгать надо было 6 лет назад, когда это все начиналось.
А лучше и еще раньше, когда статьи по дайнамо появились.

[dotcom]

6 лет назад надо было в паравоз впрыгивать. Сейчас еще не поздно присоединиться к bandwagon'у.

[crypto5]

Для писателей cassandra, mongodb, hbase, etc и т.д. может быть, а вот для писателей приложений используя их помоему серьезная/широкая адаптация их года два назад а то и год как началась только.

[valchkou]

самое время прыгать в поезд NoSql, BigData инженеров.

Опомнился.
Туда прыгать надо было 6 лет назад, когда это все начиналось.
А лучше и еще раньше, когда статьи по дайнамо появились.

Не знаю как в ваших краях, но у нас корпы сидят на sql, и еще долго на нем сидеть будут.
Только в последнее время начал наблюдаться небольшой интерес к NoSql.
Понятно что стартапы и прочие инноваторы давно этим промышляют,
но корпы это как раз то самое плодородное место обитания админов.
Считаю, что прыгать еще не поздно.
Другое дело что навыки нужны более сисадминские чем DBA. Но у дибиёв обычно с этим нет проблем.

[nightmare2]

Не знаю как в ваших краях, но у нас корпы сидят на sql, и еще долго на нем сидеть будут.
Только в последнее время начал наблюдаться небольшой интерес к NoSql.
Понятно что стартапы и прочие инноваторы давно этим промышляют,
но корпы это как раз то самое плодородное место обитания админов.
Считаю, что прыгать еще не поздно.
Другое дело что навыки нужны более сисадминские чем DBA. Но у дибиёв обычно с этим нет проблем.

У NoSql своя (пока не очень большая) ниша у Sql своя.
На мой взгляд, NoSql реляционные БД никак не отменятет, а скорее дополняет.

[kostik78]

На мой взгляд, NoSql реляционные БД никак не отменятет, а скорее дополняет.

+1 Обе технологии решают разные задачи и обе будут вместе существовать. А те кто говорит что все можно сделать на NoSQL и Oracle/Postgres/VerticaDB/Greenplum нам не нужен либо лукавят, либо плохо знают NoSQL Сделать то можно, вот как работать будет Яркий пример: реляционные транзакционые БД плохо работают в распределенных системах, хотя народ упорно пытался/пытается их применять

[nightmare2]

На мой взгляд, NoSql реляционные БД никак не отменятет, а скорее дополняет.

+1 Обе технологии решают разные задачи и обе будут вместе существовать. А те кто говорит что все можно сделать на NoSQL и Oracle/Postgres/VerticaDB/Greenplum нам не нужен либо лукавят, либо плохо знают NoSQL Сделать то можно, вот как работать будет Яркий пример: реляционные транзакционые БД плохо работают в распределенных системах, хотя народ упорно пытался/пытается их применять

A че выбор был/есть?
Меня вообще никто не спрашивает, какую БД использовать.

[ПростоНик]

kostik78,
не могли бы вы развить тему по поводу "реляционные транзакционые БД плохо работают в распределенных системах, хотя народ упорно пытался/пытается их применять" ?
Всю жизнь работаю с такими системами, и еще никто не жаловался.

[nightmare2]

kostik78,
не могли бы вы развить тему по поводу "реляционные транзакционые БД плохо работают в распределенных системах, хотя народ упорно пытался/пытается их применять" ?
Всю жизнь работаю с такими системами, и еще никто не жаловался.

Он, вероятно, имел ввиду распределенные транзакции.

[valchkou]

На мой взгляд, NoSql реляционные БД никак не отменятет, а скорее дополняет.

А давайте возьмем конкретный проект, и попробуем дополнить одно другим.
У нас NoSql пришел, чтобы убить SQL. Держать обе и накладно и смысла нет.

[nightmare2]

А давайте возьмем конкретный проект, и попробуем дополнить одно другим.
У нас NoSql пришел, чтобы убить SQL. Держать обе и накладно и смысла нет.

Из NoSql я знаком только с Монго.
Если я правильно понимаю идею NoSQL - это пары ключ/значение.
Используя, к примеру, механизм хеширования можно достичь высокой скорости чтения и записи по ключу.
Но что будет, если необходимо выбрать множество данных не по ключу?
Например построить како-нибудь отчет о продажах.
Или сделать какой-нибудь анализ по всей базе?
Подозреваю, что будет очень медленно.

[GarikToo]

Помоему сейчас тренд - это базы данных на Hadoop. Многие уже поняли что Hive это очень медленно и отстойно

[valchkou]

А давайте возьмем конкретный проект, и попробуем дополнить одно другим.
У нас NoSql пришел, чтобы убить SQL. Держать обе и накладно и смысла нет.

Из NoSql я знаком только с Монго.
Если я правильно понимаю идею NoSQL - это пары ключ/значение.
Используя, к примеру, механизм хеширования можно достичь высокой скорости чтения и записи по ключу.
Но что будет, если необходимо выбрать множество данных не по ключу?
Например построить како-нибудь отчет о продажах.
Или сделать какой-нибудь анализ по всей базе?
Подозреваю, что будет очень медленно.

часть задач решается с помощью индексов, в NoSql, в частности Cassandra они есть. Да не такие умные как в sql, но есть.
Для другой части придумали mapreduce, как пример hadoop. И пока что я вижу огромный интерес к этому у BigData analytics проектов.
Не хотят они оракл использовать, по каким то причинам, который умеет анализ по всей базе делать.
У Nosql есть свой огромный недостаток - нужно многие вещи делать ручками, типа merge, sort, filter.
Для этого требуются толковые программисты, а взять их пока негде.

[Леонид Ильич Брежнев]

часть задач решается с помощью индексов, в NoSql, в частности Cassandra они есть. Да не такие умные как в sql, но есть.

индексы нынче почти у всех есть. И в монго, и в дайномо, и даже в кауче что-то такое имеется.

[GarikToo]

Не хотят они оракл использовать, по каким то причинам,

Oracle license будет стоить больше чем весь стартап

[nightmare2]

часть задач решается с помощью индексов, в NoSql, в частности Cassandra они есть. Да не такие умные как в sql, но есть.
Для другой части придумали mapreduce, как пример hadoop. И пока что я вижу огромный интерес к этому у BigData analytics проектов.
Не хотят они оракл использовать, по каким то причинам, который умеет анализ по всей базе делать.
У Nosql есть свой огромный недостаток - нужно многие вещи делать ручками, типа merge, sort, filter.
Для этого требуются толковые программисты, а взять их пока негде.

Далеко не всем нужно Big Data.
Оно конечно модно и круто, но все еще достаточно экзотично.
Слоненок пока еще только в альфа версии.

Для большинства прикладных задач sql с головой хватит.
И NoSql все еще могут быть полезны как оперативное хранилище с последующей выгрузкой в реляционные или аналитические БД для анализа и отчетов.

В будущем, предполагаю добавление NoSql функций к реляционным БД. Сделать это совсм не сложно и от SQL не нужно отказываться.

Конечно если все уйдет в "облака", что будет удивительно, тогда возможно SQL будет медленно отмирать.

[nightmare2]

Блин, может мне кто-нибудь объяснить почему "Привет" так тормозит?
Это дело в БД или что-то еще?

[nightmare2]

Не хотят они оракл использовать, по каким то причинам,

Oracle license будет стоить больше чем весь стартап

Вот поэтому Биг Дата и привлекает народ.
Оракл конкретно зажрался без конкуренции.

[valchkou]

Для большинства прикладных задач sql с головой хватит.
И NoSql все еще могут быть полезны как оперативное хранилище с последующей выгрузкой в реляционные или аналитические БД для анализа и отчетов.

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

Да для небольших задач и sql база работает замечательно, типа той же derby, на яве и без установки.
Но такие проекты админов не требуют.

В будущем, предполагаю добавление NoSql функций к реляционным БД. Сделать это совсм не сложно и от SQL не нужно отказываться.

Вы рассуждаете как наши топ манагеры.
Попробуйте сделать! хотя конечно понятие сложности у всех разное.