>> Вообще-то Google крутит у себя очень большие базы. как и Facebook. Да,
>> NoSQL.
> Неужели нет других примеров, кроме Гугла?есть. вагон и маленькая тележка. эти двое просто наиболее известные.
например, Лаборатория Касперского использует Cassandra, подробности
и ссылка на видео доклада здесь: http://habrahabr.ru/company/it_people/blog/207062/
> Вроде бы, очевидно, что мало у каких компаний сервера исчисляются сотнями тысяч,
зато десятками тысяч сервера исчисляются у большого количества компаний.
просто были разговоры о том, что очень крупные задачи можно решить только
с помощью Solaris + SPARC, вот выше два контрпримера, что это далеко не так.
> а значит - для 99,99% случаев сей пример совершенно неприменим.
В чем принципиальная разница между задачами, которые работают на сотнях тысяч
серверов и задачами, которые работают на десятках тысяч серверов? и там и там -
SQL варианты решений не будут работать в силу своих ограничений и недостатков.
> Там другой подход к работе и другой тип нагрузок в целом, там
> использование максимально дешевых компонентов полностью оправдано,
> т.к. упор в таких кластерах делается на число, а не надежность,
> или вычислительные способности.
и тем не менее, гугл успешно строить высоконадежные системы,
используя кластера из большого количества "обычных" серверов.
Упор там и на надежность как один из основных приоритетов,
я еще не помню случая, чтобы гугловский кластер терял данные,
они там хранятся минимум в трех экземплярах, на трех разных серверах.
>> Выходит не настолько необходимыми являются эти спарки с солярами для BIG DATA.
> Смотря какие это данные. Впрочем, раз в пример снова привели Гугль -
> значит, явно нет понимания в чем разница между большим количеством данных
> (любых) и, собственно, большим объемом SQL-баз с более-менее сложной логикой работы.
Понимание есть. Большой объем SQL-баз - это купить дорогущий сервер,
поставить на него Oracle и молиться, чтобы ничего не упало.
Но как показывает опыт Сбербанка - сбои бывают и в таких "супернадежных" конфигурациях.
http://banks.cnews.ru/top/2012/07/06/masshtabnyy_sboy_porazi...
http://corp.cnews.ru/top/2012/07/09/itdirektor_sberbanka_ras...
переход от oldSQL -> NoSQL -> NewSQL
мне чем-то напоминает состоявшийся ранее переход
однопроцессорные -> многопроцессорные -> многоядерные+многопроцессорные
да, у SQL баз данных есть одно преимущество, ACID,
но при желании, ACID есть и у NoSQL, например, https://foundationdb.com/
но вот недостатки SQL - плохая масштабируемость,
и что с этим делать, если объемы данных постоянно ростут?
это как постоянно повышать частоту у одноядерного процессора.
но рано или поздно будет такой момент, когда повышать уже просто некуда.
а стоимость hardware для таких SQL серверов будет равна стоимости полета на марс.
и что тогда делать компаниям-потребителям таких продуктов, и что делать вендорам?
это ведь тупиковый путь развития, и гугл показывает путь которым можно идти,
это их база данных, построенная по технологии NewSQL, в частности Spanner.
понятное дело, что пока что аналоги с открытым кодом не дотягивают,
но в этой модели развития нет теоретических тупиков и нет наращивания
мощности путем вертикального масштабирования. будущее за горизонтальным
масштабированием и NewSQL/NoSQL базами данных.
>> Жолуди (патчи) падали от Red Hat`а. и Оракл это прекрасно знает.
> ZFS и DTRace внезапно изобрели в RHEL? Интересная новость.
у ZFS такая лицензия, что использовать его в линуксе нельзя.
а btrfs сообщество рано или поздно допилит до рабочего состояния,
и это, между прочим будет более эффективный и производительный вариант,
чем оракловская ZFS.
DTrace ?
Из-за лицензии CDDL, несовместимой с GPL, портирование в Linux возможно, но не легитимно. Для Linux разрабатывается утилита с близкой функциональностью под названием SystemTap на основе механизма инструментирования kprobes.
учитывая тенденции развития, SystemTap догонит и перегонит DTrace, так что все нормально.
и вообще, при чем тут Oracle разве ZFS и DTrace изобрели в Oracle ?
> А если серьезно - может быть хватит перемешивать факты, доводы, их последовательность
> и взаимосвязь? А то даже я уже умудрился запутаться. :-)
Я попытаюсь. Но просто обидно за Oracle, что они так некрасиво поступают
на рынке Enterprise Linux систем, пытаясь зарабатывать на том, что создали другие.
Так даже Майкрософт не делает, империя зла и все такое. Они просто ищут новые рынки.
> Дальнейшее передергивание было лень даже читать, не то что комментировать, извините. :-)
Почему передергивание. Я действительно так вижу - делают отличную работу в плане Java,
и так некрасиво себя ведут на рынке Enterprise Linux. Это что, уже признаки начала конца?
