Показать сообщение отдельно
Старый 10.08.2014, 03:49   #253 (permalink)
Новичок
 
Регистрация: 09.08.2014
Сообщений: 5
Вы сказали Спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Сказал(а) Фууу!: 0
Сказали Фууу! 0 раз(а) в 0 сообщениях
Откуда: MSK
Авто: W203 C240 4M
По умолчанию

Цитата:
Сообщение от ExiveR Посмотреть сообщение
Не отклоняйтесь от темы разговора - никакого "прямого доступа к базе 10ТБ и выше минуя драйвера системы" нет. "Вполне может быть" и ЕСТЬ - очень большая пропасть и абсолютно все используют проверенные способы и методы. Очень сомневаюсь, что ваш подзащитный вообще знаком с технологией распараллеливания БД, т.к. это довольно специфическое направление. Не потому ли он быстро сдулся и покинул тему?! Ну и уж подавно там и речи быть не может о "прямом доступе к железу", т.к. управлять всем этим будет кластер через инструменты ОС.
Ну, во-первых, он не мой подзащитный, я просто очень не люблю огульных обвинений. Во-вторых, лично я не имел возможности быть знакомым со абсолютно всеми видами и типами БД, которые только существуют, уверен, что вы тоже, тем не менее, я допускаю, что в ряде случаев, как например обработка данных с ускорителей, расчет ядерных моделей и реакций, ПО для управления БД может быть особо специфичным и не использовать общепринятые готовые программные механизмы. Под "напрямую к железу" подразумевается, разумеется, не сигнальный уровень, а исключение некоторых прослоек ОС, которые используются в бытовых системах, но могут снизить производительность в промышленных. Например, взаимодействие с диском: зачем использовать дополнительную прослойку в виде ФС, которая почти наверняка снизит производительность, когда ядро БД вполне может само управлять диском через ATA команды. Более того, иногда под БД могут сделать целую обособленную ОС, это тоже один из вариантов "прямого доступа к железу".
kibermaster вне форума   Ответить с цитированием