Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
 Большая таблица, мало RAM  [new]
thehil
Member

Откуда:
Сообщений: 70
Какие существуют бесплатные решения позволяющие работать с большими таблицами (1 млрд.) на железе с ограниченной RAM. Т.е. когда даже индексы целиком не помещаются в память и невозможно расшардить таблицу на несколько машин.
Что можно придумать кроме партицирования чтобы получить хотя бы примерно линейную зависимость производительности от количества строк? При том что даже в случае партицирования могут быть запросы читающие со всех партиций. Спасибо.
19 янв 12, 13:55    [11932507]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
miksoft
Member

Откуда:
Сообщений: 38919
thehil
Что можно придумать кроме партицирования чтобы получить хотя бы примерно линейную зависимость производительности от количества строк? При том что даже в случае партицирования могут быть запросы читающие со всех партиций. Спасибо.
А она и так будет линейной в худшем случае. И с очень большим множителем (из-за физического ввода-вывода).
Обычно стремятся сделать быстрее, чем линейную. В чем помогают, например, индексы.
19 янв 12, 13:59    [11932558]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
miksoft
Member

Откуда:
Сообщений: 38919
thehil,

Вы огласите задачу более детально. Пока же ничего определенного сказать нельзя. Может, любая СУБД будет одинаково плоха. А может, обычные файлы спасут.
19 янв 12, 14:00    [11932570]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
thehil
Member

Откуда:
Сообщений: 70
И да, аналитики совсем не нужно, больше на OLTP похоже.
19 янв 12, 14:00    [11932575]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
thehil
Member

Откуда:
Сообщений: 70
Производительность не будет линейной хотя бы из за того что при небольшом количестве записей индексы влазят в память, при большом - уже ничего не влазит. Доступ к строкам примерно равномерный, нету распределения по времени. Большинство запросов по ПК, часть - по другим индексированным полям.
19 янв 12, 14:03    [11932599]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
miksoft
Member

Откуда:
Сообщений: 38919
thehil
Производительность не будет линейной хотя бы из за того что при небольшом количестве записей индексы влазят в память, при большом - уже ничего не влазит.
Да, по достижении некоторого порога будет скачок, но за ним картина опять будет той же (с индексом - логарифмическйи рост, без индекса - линейный).
19 янв 12, 14:11    [11932681]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
thehil
Member

Откуда:
Сообщений: 70
miksoft
thehil
Производительность не будет линейной хотя бы из за того что при небольшом количестве записей индексы влазят в память, при большом - уже ничего не влазит.
Да, по достижении некоторого порога будет скачок, но за ним картина опять будет той же (с индексом - логарифмическйи рост, без индекса - линейный).


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

Нужны ещё варианты. Причем бесплатные.
19 янв 12, 14:15    [11932730]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
А партиционирование где бесплатное?
19 янв 12, 14:18    [11932760]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
miksoft
Member

Откуда:
Сообщений: 38919
thehil
Это и понятно, цель - преодолеть скачок.
Никак не преодолете. Либо физический ввод/вывод не нужен (нужные данные есть в ОП), либо нужен. Во втором случае совсем другие времена.

Максимум, что в этой ситуации поможет, имхо:
1) правильный алгоритм кэширования, чтобы для наиболее критичных по времени запросов была выше вероятность обойтись данными в ОП.
2) правильное использование индексов и других механизмов СУБД, позволяющие минимизировать физический ввод/вывод. И не вовсе не факт, что партиционирование тут поможет.

Пока не описана четко задача - можно теоретизировать бесконечно. Оптимизировать можно только частный случай.
19 янв 12, 14:24    [11932829]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
В случае Oracle, партишионирование поддерживает только EE - это сотни тысяч долларов на один сервер. С DB2 аналогично.

Postgres?
19 янв 12, 14:34    [11932944]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
thehil
Member

Откуда:
Сообщений: 70
Victor Metelitsa,

Да PostgreSQL поддерживает, да и на крайний случай MySQL тоже может.

Насчет подробнестей - уточните что вы ещё хотите услышать?
Есть отностительно слабый сервер, из железа больше ничего. Есть таблица с миллионами строк, хочется чтобы разростание до миллиардов не привело к заметному ухудшению времени отклика. Апп сервер на той же машине. Запросов не много, до нескольких в секунду. Запросы элементарные: дай/удали/измени строку по id в основном (80%), немного запросов по другим полям из этой же таблицы, использующие индекс (10%), есть несколько джойнов с такой же большой таблицей по id. Везде индексы и на небольших объёмах данных отклик устраивает.
19 янв 12, 14:43    [11933038]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
нелинейную зависимость в OLTP
Guest
thehil, А про нелинейную зависимость в OLTP от размера таблицы это вы тестами определили или предположили?
19 янв 12, 14:45    [11933056]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
thehil
Member

Откуда:
Сообщений: 70
Была мысль насчет шардинга mongodb на одной машине, но походу это гиблое дело.
19 янв 12, 14:45    [11933060]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
thehil
Member

Откуда:
Сообщений: 70
нелинейную зависимость в OLTP,

Предположин, да и люди выше подтвердили. Пока всё в памяти - логарифмически, как только не влазит - должно хуже. Сейчас попробую провести тест в условиях ограниченной памяти.
19 янв 12, 14:47    [11933076]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
miksoft
Member

Откуда:
Сообщений: 38919
thehil
Запросов не много, до нескольких в секунду.
Ну тут и с дисковыми чтениями ничего страшного не будет.
19 янв 12, 14:47    [11933078]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Сколько ОЗУ? Какая СУБД?
Guest
thehil
Victor Metelitsa,

Да PostgreSQL поддерживает, да и на крайний случай MySQL тоже может.

Насчет подробнестей - уточните что вы ещё хотите услышать?
Есть отностительно слабый сервер, из железа больше ничего. Есть таблица с миллионами строк, хочется чтобы разростание до миллиардов не привело к заметному ухудшению времени отклика. Апп сервер на той же машине. Запросов не много, до нескольких в секунду. Запросы элементарные: дай/удали/измени строку по id в основном (80%), немного запросов по другим полям из этой же таблицы, использующие индекс (10%), есть несколько джойнов с такой же большой таблицей по id. Везде индексы и на небольших объёмах данных отклик устраивает.

Сколько ОЗУ? Какая СУБД?
Первые 2-3 уровня индекса будут закэшированы. Партиционирование это фактически ещё один уровень индекса. Здесь удобство бывает в том, что с партициями можно работать как с обычными таблицами и переносить их между тейблспейсами и соотвественно на другие СХД.
19 янв 12, 14:49    [11933103]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
thehil
Member

Откуда:
Сообщений: 70
miksoft,

Возможно. Но в любом случае чтение с диска заметно медленнее чем из памяти. В случае с партицирование есть шанс выделить наиболее используемые данные в одну партицию и тогда шанс попадание в кеш индекса для этой партиции должен быть выше.
19 янв 12, 14:51    [11933119]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
нелинейную зависимость в OLTP
Guest
thehil
нелинейную зависимость в OLTP,

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

Если подтвердиться то только шардинг, кластер или добавлять памяти.
19 янв 12, 14:52    [11933126]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
нелинейную зависимость в OLTP
Guest
thehil
miksoft,

Возможно. Но в любом случае чтение с диска заметно медленнее чем из памяти. В случае с партицирование есть шанс выделить наиболее используемые данные в одну партицию и тогда шанс попадание в кеш индекса для этой партиции должен быть выше.

Попробуйте "провести тест в условиях ограниченной памяти." и если будут ухудшения, то попробуйте от них избавиться "выделить наиболее используемые данные в одну партицию и тогда шанс попадание в кеш индекса для этой партиции должен быть выше.".
19 янв 12, 14:54    [11933142]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
thehil
Member

Откуда:
Сообщений: 70
Сколько ОЗУ? Какая СУБД?
Сколько ОЗУ? Какая СУБД?
Первые 2-3 уровня индекса будут закэшированы. Партиционирование это фактически ещё один уровень индекса. Здесь удобство бывает в том, что с партициями можно работать как с обычными таблицами и переносить их между тейблспейсами и соотвественно на другие СХД.

Сейчас PostgreSQL, но возможно поменять на абсолютно любую бесплатную. ОЗУ может меняться, т.к. приложение целиком с базой ставится на клиентский сервер. Давайте предположим что минимум 4 Gb ОЗУ.
19 янв 12, 14:54    [11933145]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
thehil
Member

Откуда:
Сообщений: 70
нелинейную зависимость в OLTP
thehil
нелинейную зависимость в OLTP,

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

Если подтвердиться то только шардинг, кластер или добавлять памяти.

К сожалению все эти варианты сразу отпадают.
19 янв 12, 14:55    [11933152]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
miksoft
Member

Откуда:
Сообщений: 38919
thehil
miksoft,

Возможно. Но в любом случае чтение с диска заметно медленнее чем из памяти.
Пока не озвучены четкие цифры вида "такой-то SQL-запрос на таких-то данных отрабывает за X секунд, а допустимо не более чем за Y секунд в Z% случаев" ваши фразы типа "заметно медленнее" - ни о чем.
19 янв 12, 14:55    [11933153]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Yo.!
Guest
Victor Metelitsa
В случае Oracle, партишионирование поддерживает только EE - это сотни тысяч долларов на один сервер. С DB2 аналогично.

Partition Views есть в любой оракловой редакции
http://docs.oracle.com/cd/A57673_01/DOC/server/doc/A48506/partview.htm#351

в постгрес взрослого партитионинга нет, но есть те же самые Partition Views
19 янв 12, 14:58    [11933169]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
thehil
Есть отностительно слабый сервер, из железа больше ничего. Есть таблица с миллионами строк, хочется чтобы разростание до миллиардов не привело к заметному ухудшению времени отклика. Апп сервер на той же машине. Запросов не много, до нескольких в секунду. Запросы элементарные: дай/удали/измени строку по id в основном (80%), немного запросов по другим полям из этой же таблицы, использующие индекс (10%), есть несколько джойнов с такой же большой таблицей по id. Везде индексы и на небольших объёмах данных отклик устраивает.


Загрузите тестовыми данными, да посмотрите. Лично мне кажется, что при такой абстрактной постановке и с миллиардами записей будет терпимо работать (причём даже без партишионирования, но при наличии подходящих индексов). Вот бекапы делать - это да...
19 янв 12, 15:01    [11933192]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Yo.!
Victor Metelitsa
В случае Oracle, партишионирование поддерживает только EE - это сотни тысяч долларов на один сервер. С DB2 аналогично.

Partition Views есть в любой оракловой редакции
http://docs.oracle.com/cd/A57673_01/DOC/server/doc/A48506/partview.htm#351

А... Я уже забыл про эту фичу (в DB2 такое можно также на любых версиях)
19 янв 12, 15:09    [11933263]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить