На отечественных серверах начал работать первый дата-центр

> хотелось бы сравнения с зарубежными аналогами

Реальная производительность АРМ Эльбрус на ОС Windows будет на уровне AMD Athlon 64 2,211 Ггц (2003).
Насчот серверов инфу за 5 минут не нашел.

> Это по каким тестам?

[censored]

> Она без перебоев обрабатывает 35-40 тыс. запросов в сутки на оформление документов нового образца.

Ничего себе! Вот это мощ
Странно если бы такая "нагрузка" ещё и перебои давала.

> Ничего себе! Вот это мощ
>

На автомате прочитал "запросов в секунду". А тут меньше чем запрос в 2 секунды. Действительно впечатляющая мощь.

Может, там просто диалап???

> По словам эксперта, система функционирует круглосуточно и хранит 20 терабайт информации. Она без перебоев обрабатывает 35-40 тыс. запросов в сутки на оформление документов нового образца

[censored]

130 серверов и 40000 запросов. Ну, может быть трафик не генерит никто. А максимум-то какой?

> 35-40 тыс. запросов в сутки на оформление документов нового образца.

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

> Реальная производительность АРМ Эльбрус на ОС Windows

А зачем там Windows?

Боюсь даже представить! Сколько же?

> 40 тысяч запросов в день, это примерно как 1 работающий форум, в котором с одним запросом документа можно сравнить 1 загрузку любой страницы форума

Тут такое. Структура БД форума, как правило, подразумевает работу с плоскими таблицами без выебонов.

А вот в системах, которые подразумевают какое-то расширение (ну, можно посмотреть на 1С) подразумевается хранение данных не в плоских таблицах с фиксированной структурой, а в справочниках, которые можно расширять, как душе угодно, но сама работа с ними - она существенно медленнее. Так работает, к примеру, некоторый софт в МО и в "АтомСтройЭкспорте" (это из того, что знаю сам, но думаю, что в данном дата-центре может быть что-то подобное). То есть, грубо говоря, для запроса одного документа (или одного поста в форуме) тебе надо сделать запрос не к одной-двум-трём таблицам, а к одной, но много-много раз - столько, сколько полей тебе нужно вернуть в запросе.
Это только в первом приближении, очень обобщенно.

Кроме того, многие придерживаются политики "на клиенте нельзя обращаться к таблицам, можно использовать только вьюхи". Вьюза работает, если кто не в курсе, так: сначала делается выборка всех данных, которые указаны в коде вьюхи, и только потом они фильтруются, в отличие от запроса напрямую к таблице. Чрез это нагрузка растёт. Такой подход практиковался, насколько мне известно, в одном из банков в Мск, куда я думал устроиться в 2013 году (к счастью, не устроился, нашел хорошую работу дома).

Есть еще всякое интересное. К примеру, в "РосАккредитации" данные по большей части хранятся в полях нескольких (нескольких, не в множестве, там не больше 20) таблиц БД - да, Oracle, но данные - в XML, который не индексируется (хотя оракл умеет работать с XML). Иногда в XML хранятся и подзапросы...

В общем, как говорилось в комментах выше - дело не только в железе. Так же следует смотреть и на архитектуру софта, и на радиус кривизны рук разработчика, и на диагноз гос.заказчика.

А сравнивать форум и более-менее серьезную систему - это примерно так же, как сравнить палец с известным органом.

> Речь идет об оформлении документов. Ничем там таблица данных принципиально не отличается

> А форум по твоему как работает?

Ты, мил человек, извини, то есть мнение, что ты не совсем понимаешь, о чем идёт речь.

Попробую разъяснить, чисто приблизительно, как строятся БД с произвольной структурой (без соблюдения синтаксиса, чисто алгоритмически. Ты, судя по твоим словам, понимающий):

create table DATATYPES(GUID, CODENAME, CAPTION)
create table SPR(GUID, CODENAME, CAPTION);
create table SPR_FIELDS(GUID, SPR_GUID, CODENAME, CAPTION, DATATYPES_GUID);
create table SPR_VALUES(GUID, FIELDS_GUID, VALUE);

Теперь - как построена БД форума - опять же - приблизительно:

create table USERS(ID, LOGIN, PWD, NAME);
create table FORUM_PARTS(ID, CAPTION);
create table FOCUM_MSG(ID, PRAENT_ID, USERS_ID, CAPTION, TEXT);

Как можно заметить - в первом случае сама структура более гибкая, но запросы сбуду сложнее и ресурсоёмче.
Во втором - запросы проще и работать будут быстрее, но расширять сложнее.

> С постгре я, кстати, немного знаком

Ты и правда знаком с БД и методами их построения - или только с диалектом SQL постгреса?

Там сильно отличается.

Если в двух словах - ты делаешь запрос к таблице значений, где GUID поля входит в список полей (еще запрос), которые входят в нужный справочник (еще запрос) - и так для каждого "поля" при таком раскладе.
Ну, а если еще вьюхи используются вместо прямого запроса с нужными условиями - то сначала пройдут все эти выборки )

Это не к тому, что такое нельзя использовать, конечно. Это для пояснения того, как это работает.
Всегда надо стараться использовать то решение, которое будет оптимально для решения определенной задачи. Одно плохо - не всегда всё зависит от твоего решения.

Зависит от документа и качества написания запросов. Легко создать и такой документ, который миллион запросов будет генерировать. Такой говнокод я видел у наших "партнеров" в германии.

Нагрузка боле чем скромная. И 20 терабайт конечно впечатляет:) учитывая что 1 тб накопитель сейчас ширпотреб за 2500 руб. С другой стороны, дорога в тысячу ли начинается с первого шага. Удачи! Хотя признаюсь скепсис испытываю сильный...

> ты же вроде систему учета писал?

Да. Запись в таблицу, чтение из таблицы

> аж целых 1.6 млн. ужасно много да:)

А теперь умножаем на 2, ибо RAID1, а лучше на 4, ибо RAID10.

> де-факто с этим даже обычный комп справится
> У меня например сейчас поток идёт не менее 10 тыс. транзакций в секунду.

Ну нет столько желающих оформить паспорта, что делать-то? Не писать новости, или писать, но с припиской, что это херня, у Шульца всё гораздо круче?

> Так что по характеристикам этот эльбрус-центр конечно не впечатляет

Много что из отечественного не впечатляет, но делать нужно.