Перейти к содержимому


- - - - -

СУБД


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 37

#31 downGRADE

downGRADE
  • Знаток

  • Пользователь
  • 1 092 сообщений

Отправлено 24.10.2006 - 05:12

Просмотр сообщенияJoshua5 (23.10.2006, 13:11) писал:

Что толку кешировать запрос, если у тебя несколько десятков тысяч подключений к БД в секунду? Что толку кешировать результат, если для его хранения не хватает оперативки и ОСь кидает в своп?
Если оперативки не хватает, то ось всё равно скинет результат в своп, кешируешь ты его или нет(запрос-поиск по кэшу базы-поиск по дискам базы-ответ-сброс на своп). Неограниченая потоками/подключениями база зависает раздувая своп. Я говорил о кэшировании самых массовых запросов, которые быстро отрабатываются в пулах.

Просмотр сообщенияJoshua5 (23.10.2006, 13:11) писал:

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

#32 Joshua5

Joshua5
  • Paranoid Android

  • Пользователь
  • 189 сообщений
  • Город:Ясенево

Отправлено 24.10.2006 - 10:50

Просмотр сообщенияdownGRADE (24.10.2006, 6:12) писал:

Если оперативки не хватает, то ось всё равно скинет результат в своп, кешируешь ты его или нет(запрос-поиск по кэшу базы-поиск по дискам базы-ответ-сброс на своп).

Я об этом и говорю. Надо вообще избавляться от работы с диском и работать только с оперативкой.

Цитата

Неограниченая потоками/подключениями база зависает раздувая своп. Я говорил о кэшировании самых массовых запросов, которые быстро отрабатываются в пулах.

При большом количестве запросов это всё равно не спасёт... Тут нужны однородные выборки, а если они все разные? Лучше в таком случае засасывать всю таблицу в память для ускорения выборок (например, на RAM-drive, хотя это и не самый лучший метод).

#33 downGRADE

downGRADE
  • Знаток

  • Пользователь
  • 1 092 сообщений

Отправлено 24.10.2006 - 21:36

Просмотр сообщенияJoshua5 (24.10.2006, 11:50) писал:

Я об этом и говорю. Надо вообще избавляться от работы с диском и работать только с оперативкой.
Нельзя в базе данных избавится от работы с диском, эффективно работать с дисками, это основное предназначение СУБД.

Просмотр сообщенияJoshua5 (24.10.2006, 11:50) писал:

При большом количестве запросов это всё равно не спасёт... Тут нужны однородные выборки, а если они все разные? Лучше в таком случае засасывать всю таблицу в память для ускорения выборок (например, на RAM-drive, хотя это и не самый лучший метод).
При оптимальном ограничении потоков, ось в своп сливает лишние запросы, а не ответы.

#34 Joshua5

Joshua5
  • Paranoid Android

  • Пользователь
  • 189 сообщений
  • Город:Ясенево

Отправлено 25.10.2006 - 13:16

Просмотр сообщенияdownGRADE (24.10.2006, 22:36) писал:

Нельзя в базе данных избавится от работы с диском

Ой ли? :) Для селектов точно можно.

Цитата

эффективно работать с дисками, это основное предназначение СУБД.При оптимальном ограничении потоков, ось в своп сливает лишние запросы, а не ответы.

Это как, интересно? С каких пор у ОСи есть доступ к запросам? :) Туманные ответы выдают незнание предмета... Ты случайно не в курсе, что текст запроса, например в MySQL, хранится вместе с таблицей ответа? :P Вообще, представляешь себе, что такое Query Cache? По-моему, не особенно.

Сообщение отредактировал Joshua5: 25.10.2006 - 13:17


#35 downGRADE

downGRADE
  • Знаток

  • Пользователь
  • 1 092 сообщений

Отправлено 27.10.2006 - 06:52

Просмотр сообщенияJoshua5 (25.10.2006, 14:16) писал:

Ой ли? :) Для селектов точно можно.
Можно конечно базу, как калькулятор использовать.  :)
Только она ведь не для этого, правда ведь?

Просмотр сообщенияJoshua5 (25.10.2006, 14:16) писал:

Это как, интересно? С каких пор у ОСи есть доступ к запросам? :P Туманные ответы выдают незнание предмета... Ты случайно не в курсе, что текст запроса, например в MySQL, хранится вместе с таблицей ответа? :P Вообще, представляешь себе, что такое Query Cache? По-моему, не особенно.
Чтобы запрос начал обрабатываться, сервер базы должен запустить системный поток обработки, пока лимит потоков превышен, поступающие запросы торчат в буфере и не обрабатываются... под их обработку не выделяется память и процессорное время, соответстивие производительности системы потребностям поступающих запросов - условие оптимальности.

#36 Joshua5

Joshua5
  • Paranoid Android

  • Пользователь
  • 189 сообщений
  • Город:Ясенево

Отправлено 27.10.2006 - 16:04

Просмотр сообщенияdownGRADE (27.10.2006, 7:52) писал:

Можно конечно базу, как калькулятор использовать.  :)
Только она ведь не для этого, правда ведь?

Бред. База хранит данные и должна уметь их отдавать. Более того, её основное предназначение - как раз отдавать эти даные в различном виде.

Цитата

Чтобы запрос начал обрабатываться, сервер базы должен запустить системный поток обработки, пока лимит потоков превышен, поступающие запросы торчат в буфере и не обрабатываются... под их обработку не выделяется память и процессорное время, соответстивие производительности системы потребностям поступающих запросов - условие оптимальности.

Ёпрст... а всё это вот как-нибудь попроще нельзя было сказать? Например, "запросы обрабатываются по очереди"? Окей, я понял, что ты имел в виду, правда Query Cache здесь вообще ни при чём (зачем кешировать текст запроса, если он ни разу не выполнен?). Проблема с кучей запросов в очереди решается увеличением буфера. При той же производительности железа сервера.

Сообщение отредактировал Joshua5: 27.10.2006 - 16:05


#37 downGRADE

downGRADE
  • Знаток

  • Пользователь
  • 1 092 сообщений

Отправлено 27.10.2006 - 16:39

Блин, какой то тупой разговор получается...

Просмотр сообщенияJoshua5 (24.10.2006, 11:50) писал:

Я об этом и говорю. Надо вообще избавляться от работы с диском и работать только с оперативкой.
Говоришь, что с оперативкой надо работать...

Просмотр сообщенияdownGRADE (24.10.2006, 22:36) писал:

Нельзя в базе данных избавится от работы с диском, эффективно работать с дисками, это основное предназначение СУБД.
Возражаю, что базы на дисках, и размер её немаленький, в память точно не влезет, сервер СУБД должен быстро делать выборки по дискам, для этого у него в потрохах куча прибамбасов наворочена...

Просмотр сообщенияJoshua5 (25.10.2006, 14:16) писал:

Ой ли? :) Для селектов точно можно.
Отвечаешь, селекты можно, значит арифметика и функции, потому что приводить выборки по базам в требуемый вид, это всё равно после работы с дисками базы...

Просмотр сообщенияdownGRADE (27.10.2006, 7:52) писал:

Можно конечно базу, как калькулятор использовать.  :)
Только она ведь не для этого, правда ведь?
Отвечаю намёком на это обстоятельство...

Просмотр сообщенияJoshua5 (27.10.2006, 17:04) писал:

Бред. База хранит данные и должна уметь их отдавать. Более того, её основное предназначение - как раз отдавать эти даные в различном виде.
Говоришь, отдавать - главное, как отдавать, если гиги данных на хардах в базе? Только поиском по этим гигам...

#38 Joshua5

Joshua5
  • Paranoid Android

  • Пользователь
  • 189 сообщений
  • Город:Ясенево

Отправлено 30.10.2006 - 13:36

Просмотр сообщенияdownGRADE (27.10.2006, 17:39) писал:

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

А вся база в памяти и не нужна, только её наиболее используемые части. Впрочем, большая - это понятие относительная. У нас она около 20-и гигов и все необходимые таблицы преспокойно сидят в памяти.

Цитата

сервер СУБД должен быстро делать выборки по дискам, для этого у него в потрохах куча прибамбасов наворочена...

При большой нагрузке они не помогают.




Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 скрытых пользователей