Алексей КVoDAдальше javaEE кластера работают по принципу "облака", т.е. множество серверов в параллель обрабатывают данные.На СУБД кластера не делают?
И много ли вы кластерных БД знаете? По заверениям в соседнем форуме только DB2 на мейнфрейме и в некоторой степени Oracle RAC есть. Во всех остальных кластеризация не увеличивает производительсноть, а только надежность.

Алексей КПлюс отсутствие оверхеда на передачу данных между AppServer <=> DBServer.
И сколько этот overhead? А вы думали о том, что стоимость передачи данных от БД до сервера приложений может быть меньше стоимости передачи данных от дисковой подсистеме к БД?

1024авторИ сколько этот overhead? А вы думали о том, что стоимость передачи данных от БД до сервера приложений может быть меньше стоимости передачи данных от дисковой подсистеме к БД?

что за бред. Скорость считывания данных из хранилища это и есть суть работы любой СУБД.
Что-то вы непонятное написали. Вчитайтесь в мое сообщение.

1024авторИ сколько этот overhead? А вы думали о том, что стоимость передачи данных от БД до сервера приложений может быть меньше стоимости передачи данных от дисковой подсистеме к БД?

что за бред. Скорость считывания данных из хранилища это и есть суть работы любой СУБД.

http://en.wikipedia.org/wiki/SCSI - самый быстрый SCSI - 5120 Mbit/s

http://en.wikipedia.org/wiki/10_Gigabit_Ethernet - 10 Gbit/s если один канал и больше если несколько

Т.е. канал между сервером приложений и сервером БД быстрее, чем канал между БД и диском.
Чтобы на практике было не так, люди идут на ухищрения, такие как RAID и покупка SSD.

1024Простой тест. Вот твой Client.getClientDebts()
Ясно что это в простейшем случае 3 таблицы клиенты (наименование), операции (дата, тип), типы операций (приход/расход). Напиши запрос который получает какой клиент сколько должен или ему должны на определённую дату. Понятия не имеешь как это делается? Так зачем лезть и спорить?
SELECT с суммированием или что-то более "хитрое" у вас на уме? И почему, интересно, суммирование тот же Oracle будет быстрее делать, чем моя программа на Java, если предположить, что оба на одинаковом железе и одинаковой ОС?

1024какой канал? Склсервер это не куча файлов с данными, это прежде всего организация данных в удобном для обработки виде.

Понятие "индекс" говорит о чёмнить? Во многих случаях скл сервер считывает только малую часть данных либо очень малую часть.

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

Чем так индекс принципиально отличается от хорошей хеш-таблицы? Поиск по хеш-таблице имеет сложность O(log(n)). Вы утверждаете, что сервер БД каким-то образом умеет искать эффективней, чем O(log(n))?

Потом, я не понял где это "там" скорость различается на порядки.

Вообщем - вот задача. Есть DBF файл с данными по платежам за месяц. Нужно подсчитать сколько заплатил за месяц конкретный клиент. Теперь вопрос - кто быстрее справится, сервер БД (любой) или программа на Java? Насколько быстрее?

Мой ответ - очень удивлюсь, если будет разительная разница в результатах.

Не нужно сравнивать апельсины с яблоками. Если вы используете современную БД с правильно настроенными индексами и прочими "наворотами" для выполнения SQL запроса и обычный текстовый файл в случае Java, разумеется, первый будет на порядки быстрее. Нужно уравнивать условия задачи, если уж говорить о сравнении.

1024В случае если сделать запросом скл сервер ничего никуда передавать не будет, данные он также полностью считывать не будет. Получится разница в скорости... ну, раз в 100 скажем.
ОК. Я утверждаю, что засчет развития сетевых технологий стоимость передачи данных между двумя рядом стоящими серверами не является столь важным критерием, как производительность программы или диска.

Если клиент получил 10 платежей, как сервер БД может найти сумму считывая данные только 6 платежей? Никак.

1024авторИ почему, интересно, суммирование тот же Oracle будет быстрее делать, чем моя программа на Java

потому что для расчёта на жаве ораклу надо будет считать таблицы и передать жавапрограмме. Жавапрограмма должна записать данные на диск (мы же говорим о нормальных размерах) и произвести расчёт. Можно конечно сразу расчитывать при поступлении через ждбц но поклонникам орм это как самолёт дикарю.
Зачем записывать на диск данные, которые не нужно хранить? Вы уж Java-программистов за полных идиотов не считайте, пожалуйста. Я не предлагаю сравнивать производительность оптимизированного сервера БД со скоростью программы на Java, которая прежде чем что-то посчитать обернет данные в обертки несколько раз и сохранит данные на диск "на всякий случай" или там потратит всю память и умрет с OutOfMemoryError.

P.s. я не предлагаю выбрость БД. Для большинства проектов использование коммерческой БД - лучший способ снизить стоимость разработки, стоимость поддержки и увеличить надежность ИТ решения в целом.

1024авторЯ утверждаю, что засчет развития сетевых технологий стоимость передачи данных между двумя рядом стоящими серверами не является столь важным критерием, как производительность программы или диска.

ещё раз:

склсервер и реляционные бд основаны на храненнии данных в оптимизированном для обработки виде. Это означает что для многих операций (а в идеале для всех) склсервер будет обрабатывать данные так что скорость обработки будет выше скорости простого считывания.

Тестовый пример даден. Если не знаешь как его сделать то споры лучше прекратить. Нет смысла.
Еще раз. Как можно обрабатывать данные быстрее, чем скорость чтения?

Вы физичеки не можете сложить 10 чисел не прочитав их. А значит скорость сложения будет всегда ниже скорости чтения.

1024авторЕсли клиент получил 10 платежей, как сервер БД может найти сумму считывая данные только 6 платежей? Никак.

ну... Если кратко - считай что это чудо. Если развёрнуто - там много всего. Стандартные алгоритмы поиска, хорошо описанные и хорошо работающие.
Поиска чего? Если нужно сложить 10 чисел, как можно получить их сумму не прочитав данные? Как может результат сложения быть первичней слагаемых?

Собрал статистику за последнее время. Выяснилось, что порядка 20 партнеров "грешат". Наверное, нужно какое-нибудь materialized view сделать, где прописать только их. Или нет в этом никакого смысла?