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

А по поводу объединения нескольких линков - опять же сначала железо, которое способно переварить такой поток. А потом понимание того, что в серьезных решениях линки объединяют, в основном, для отказоустойчивости.
Ну, т.е. на примере, что под руками: от серверов идет по два канала 10G на два независимых свитча, на дисковой полке (замечу, из средней-средней части ценового решения) два RAID-контроллера, каждый из которых может перехватывать управление любым RAID'ом, собранном в пределах этой полки (при условии использования соответствующих дисков, конечно ), на каждом из этих контроллеров полки - по 2 (или 4, в современных вариантах) 10G интерфейса. От полки до свитчей (разных) идет не менее 4-х каналов 10G. Вот и получается нормальная такая отказоустойчивость. Да, естественно, и у сервера и у полки по два блока питания, подключенных к разным входам по питанию, с разных UPS'ов, которые д.б., в идеале, запитаны с разных входов в здание от двух разных подстанций. Ну и где-то дизелек под боком. Но это уже сильно в мечтах

Что-то меня в сторону повело Ну не стирать же приличный текст?


Традиционно считалось, что база данных должна быть отделена от сервера приложений, пока сетка не была ограничивающим фактором. Каждый должен заниматься своим делом. БД - предоставлять данные, сервер приложений обрабатывать их и отдавать их клиентам.
Да и с точки зрения отказоустойчивости гораздо проще её обеспечивать независимо для базы данных и для аппликухи. Особенно если производитель БД и сервера приложений не один и тот же.

Не было раньше таких объемов данных, которые сервер БД мог предоставить с такой скоростью. Все было более-менее сбалансировано. Скорость доступа к данным на традиционных дисках не сильно превышает скорость гигабитных сетевых каналов. В результате серверу было достаточно четырех гигабитных интерфейсов (объединяем по паре штук и получаем два двухгигабитных, отказоустойчивых канала) для доступа к любой традиционной базе данных.
А тут вот возникла мода на обработку больших массивов данных, вместе с сильным удешевлением обычных HDD. Потом выяснилось что данных-то много, но диски медленные. Стали появляться идеи с Database in memory (память тоже сильно подешевела и серверное железо стало поддерживать бОльшие объемы) и, в параллель, потихоньку потянулись SSD, сначала как кэширующие, потом как замена HDD.
Вот, в результате, и имеем то, что имеем.

А насчет вычислений на уровне БД - так HANA как раз к этому и стремится. И правильно стремится. Только неизвестно, что раньше произойдет. Полный перевод всего функционала ERP на обработку в HANA с выкидыванием сервера приложений, или удешевление SSD до уровня, когда нет смысла использовать БД in memory, или скачок в скорости сетевого взаимодействия (с точки зрения цены и доступности), когда не будет смысла обработка данных ERP в базе данных (ну, т.е. трехзвенка не будет никому мешать)

Пока, реально, радость есть только у BW'шников, которые, действительно, могут свои трансформации на БД переложить. И получить готовый комплект данных. И красиво отрисовать диаграммку, основанную на переработке пятилетней статистике продаж крупного ритейлера. Например: что ещё будет чаще всего встречаться в чеке человека, купившего полторашку Клинского? Чтобы раскладочку в магазине изменить

Увы - нет, пока, таких данных. У меня, во всяком случае. Большие конторы, у кого много данных, они не сильно поворотливы в части замены оборудования. Дорого это обходится.
Знаю одно место, где год назад, как минимум, тендер на закупку дискового массива был выигран SSD-массивом. При чем выигран, как мне говорили, по цене... Но дальнейшей информации не имею.

А Вы не могли бы эту фразу в цифры перевести? Чтобы сориентироваться проще было.

2 Кодер, HANA имеет несколько очередей ресурсов - временнего хранения, длительного хранения и невыгружаемые. При нехватке памяти, HANA освободит память удалив из памяти объекты из первой очереди, затем из второй (выгружая таблицы из памяти согласно их весу), затем запросит соседние сервисы высвободить ресурсы (nameserver, xsengine, compileserver etc.) и, если запрос на память так и не удовлетворен, то завершит его с генерацией ООМ (при условии, что лимит на стейтмент не установлен, иначе просто откатит стейтмент). Кроме того, имеется возможность для таблиц указать возможность выгрузки (это если единоразово надо получить доступ к какой-либо большой таблице для отчета, после чего эта таблица в течение долгого времени не нужна) по условию. Так что не вижу отсутствия гибкости тут. Чтобы HANA не свопила, надо подкрутить настройки ядра. Некоторые просто рекомендуют отключать своп для всей ОС, но я не сторонник такого подхода

так - подумалось просто..
а что если через ... 100Тб памяти не будут проблемой, умрут жесткие диски - Oracle DB исчезнет? С долговременным хранением тоже как-то разрешится. Что будет?

p.s. Skif много помнит, над чем кресты рассыпались уже...

2 kernelpanic:
Вы потоком слов опять "замылили" проблему. Таблицы все равно должны быть в хане полностью в памяти, даже если читается одна строка (ну или партиция, если табла секционирована). Насколько я знаю, лекарства от этого у ханы нет.

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

Ладно, мне не очень тяжело.
http://www.samsung.com/ru/consumer/memo ... Z-V5P512BW
Заметьте - консьюмерский диск.
Скорость последовательного чтения/записи до 2500/1500 млн байт сек
Перевести в биты? Это будет порядка 20 Gb/s на чтение и 12 Gb/s на запись.
Но это не совсем обычное решение по интерфейсу. Хотя если мы будем говорить про хранилища данных, изначально рассчитанные на флеш-массивы, так какие там внутри интерфейсы - уже отдельная тема.
Поэтому можно поговорить и за обычные решения, когда SSD выступает в качестве замены HDD

Если взять типовой SSD на SATA интерфейсе, во выше 6 Gb/s он не прыгнет. Скорость интерфейса. Реально они на чтение дают порядка 500+ Мегабайт в секунду. Т.е. ~ 4 Gb/s
Если взять Enterprise Class SSD Samsung PM 1633 15 Tb емкостью, с интерфейсом SAS 12 Gb/s, то у него уже заявленная скорость 1200 мегабайт в секунду на чтение и 900 - на запись. Что дает 9,6 Gb/s на чтение и 7,2 Gb/s на запись.

Сумеете сравнить в цифрах с сетевым интерфейсом на 10 Gb/s ?

Справедливости ради при таком диске 10G сеть будет полностью утилизироваться только если запросы что-то типа select * from big_table (еще и сервер приложений такой поток прожевать должен, 8 гигов памяти забьются секунд за 8 ). Интересно, какое в реальности соотношение между прочитанным с диска и отправленным в сеть, это конечно и от характера приложения, и от индексов, и от настроек, и от количества оперативки и т.д. зависит. Кто-нибудь смотрел на этот вопрос? С другой стороны и обычная БД старается по максимуму горячие данные в памяти кэшировать так что может что-то отдать и не обращаясь к диску.

Да и диск будет утилизироваться по полной именно в такие моменты. Так что баш на баш.
Но ведь у нас не однопользовательская система. Один селект - хорошо, а два - лучше
И чем больше пользователей в системе, тем больше селектов.

Ненене. Я про то что если например все пользователи сделают что-то типа select * from big_table where field like %xxx% (а если big_table'ы еще и разные будут) то, например, каждый запрос приведет к фулскану таблицы причем дуск будет утилизирован на 100%, а сеть, например, на 1 процент. Вот мне и интересно на реальных нагрузках (реальные селекты, тонны опитимазаций и кэшей в БД) во сколько раз скорость работы диска должна быть больше скорости сети чтобы сеть была утилизирована на 100%.

UPD. Это даже можно проверить на неполностью загруженной системе, снять например сколько гигабайтов было прочитано с диска и сколько отправлено в сеть за час, например (при условии что на сервере только БД и другое ПО дает минимальную нагрузку на диск и сеть)

Не совсем понимаю ситуацию. По заданным условиям выходит, что данные, которые запросил пользователь, БД снимает с диска, но пользователю они не доходят. Иначе никак не могу понять зачем они читались с диска, полностью его загрузив, но сетка осталась без нагрузки.
Как это? Такая разница бывает только в случае, когда диски сильно-сильно медленнее сетки. Когда мы говорим о примерно одинаковых скоростях дисковой системы и сетевого оборудования от потребителя до поставщика, все нагрузки тоже должны быть примерно одинаковы, если мы работаем без кэширования данны.
Если кеширование есть, то зависит от слишком многих факторов. В общем случае рулит количество повторяющихся запросов. Но все равно при равной пропускной скорости сетки и дисков не будет такой разницы в загрузке, как вы говорите. Чтобы диск загрузили на 100%, а сеть на 1%.

Зайду с другой стороны)) В общем-то основная задача базы данных хранить и быстро отдавать запрошенную информацию. Для целей быстроты и служат всякие индексы, кэши, даже сама структура хранения данных. Так вот, далеко не всегда пользователю БД нужна таблица целиком к которой он обращается, ему же нужна какая-то определенная запись или подмножество записей, какие именно записи нужны он указывает в условии WHERE (ну и плюс нужные столбцы в SELECT ... ). Обычно чтобы быстро найти запись БД использует индексы и другие техники оптимизации, но это не всегда получается. Так вот я как программист легко могу наколбасить запросы которые выливаются в фулскан таблицы (например что-то там NAME like '%Иванов%'), чтобы вернуть, например, 10 подходящих записей (например, они будут длиной по 100 байт каждая) надо будет вычитать ВСЮ таблицу с диска (например 1 миллион записей). Такие запросы, например, в EXPLAIN'е имеют огромную io-стоимость, но почти не нагружают сеть.

Можно еще менее жесткие запросы напридумывать которые нагрузят диск на 100%, а сеть меньше. Например 10 пользователей более-менее одновременно решили такие запросы отправить:
1. select saknr from ska1
2. select lifnr from lfa1
3. select kunnr from kna1
и т.д. Скорее всего это приведет к линейному чтению соответствующих таблиц в память (не будет же БД на каждую запись по новой позиционироваться чтобы считать 10 байт). А отдаваться в сеть будет процентов 1 - 10 от того что прочиталось с диска.

Все-все-все, понял о чем речь В понедельник с утра голова еще выходные, походу, обдумывает.
Я не хочу даже думать на тему таких запросов. Здесь уже все выходит за рамки обычной работы. "Ну у вас и запросы, сказала БД и повисла"
Тут не спасет ничего. Но сетка - да, будет свободна...

А вот это как раз и является вполне себе обычным вариантом работы. Мне тоже стало интересно, посмотрел сейчас статистику за один обычный рабочий день.
С интерфейса сервера, где работает продуктивная база данных (и только она) за этот день ушло в сеть порядка 200 Гб данных.
Очевидно что 99,999% объема это был трафик от базы до серверов приложений.
А судя по AWR репорту в оракле за этот же период, физических чтений с дисков проведено на 6 Тб
Вот вам и сравнение требуемой пропускной способности дисковых интерфейсов и сети до сервера приложений - в 30 раз.
Понятно что число физических чтений с диска сильно зависит от многих факторов, от объема оперативки, например.
В тот день, к слову, из буферов было считано вообще 200 теров. Можно и на эту цифру ориентироваться.
В любом случае хорошо видно соотношение сколько данных перелопачивает СУБД (и какая скорость для этого требуется) и сколько отдает в качестве результата (то есть какая нужна скорость сети).

Ну и для полноты картины, судя по ST03, за тот же день суммарно со всех серверов приложений до конечных клиентов по сети было отправлено порядка 12 Гб данных.

Спасибо, мне тоже была интересна именно эта статистика.

а есть способ на форуме организовать сводную статистику?
просто могут различаться данные в разных ипостасях
p.s. лезут мысли - "а в разрезе?", а если BW подключить