>[оверквотинг удален]
>охлаждение) потребляет около 6МВатт - то потребуется построить еще одну электростанцию
>- ибо 2МВатт надо будет откуда-то взять.
>
>Как вам такие расходы ?
>
>PS. не задумывались почему гугл хочет открыть дочернее предприятие по продаже электричества?
>
>PPS. потребляемая мощность взята не из ornl - а из японского кластера
>ti-tech который меньше того что стоит в ornl - поэтому оценка
>скорее всего занижена. Не переживайте, мы все посчитали. Вы считаете исходя из энергопотребления, которое производит стандартное серверное оборудование с малоемкими (320-750Гб), зато очень горячими и вращающимися на 15К оборотов, жесткими дисками. Которые подключены в серверные многопроцессорные материнские платы с прожорливыми серверными модификациями процессоров. При этом запиханы в корпуса с 3-10 мощнейшими высокооборотистыми вентиляторами для охлаждения всей этой печки и с парой мощных блоков питания для резерва. И вполне понятно, в системе в которой репликация не превышает единицы, предъявляются высокие требования к надежности и высокие требования к быстродействию каждого узла.
В системе же, где мы можем получать данные параллельно со множества серверов, требования к быстродействию и надежности каждого отдельного узла - существенно меньше. И мы свободно можем собирать их на основе холодных объемных жестких дисков (1,5 - 2Тб) работающих на 5400 и потребляющих на порядок меньше энергии в расчете на гигабайт пространства. И все это под управлением microatx материнских плат с процессорами аля Intel Atom на борту.
>PS. не задумывались почему гугл хочет открыть дочернее предприятие по продаже электричества?
А не задумывались почему во всех отчетах гугл хвастается своей энергоэффективностью приводя количество энергии расходуемое на один запрос пользователя. И демонстрируя цифры гораздо более привлекательные, чем у стандартных серверных решений. При этом везде хвастаясь заботой о природе, продолжая увеличивать это показатели, дальше собирая свои дешевые, на простых комплектующих, маломощные сервера.
>спасет. Причем методика примерно аналогичная тому как востанавливают базы данных после сбоя.
>
>Сначала рейд выполняет свой rebuild - потом база данных накатывает собственный лог
>изменений, что бы дотянуть базу до актуального состояния.
Каждая методика имеет ограниченную область эффективности. То что эффективно для базы данных с большим количеством мелких записей, будет абсолютно неработоспособно на файловой системе с меньшим количеством, но зато больших по объему файлов. Также надо учитывать частоту и объем обновлений. В отличии от того же лога изменений, который может пригодиться только в случае нештатной ситуации, а остальное время только в пустую расходует ресурсы, репликация увеличивает быстродействие за счет параллельного чтения данных сразу с нескольких устройств.
