|
|
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
Какие существуют бесплатные решения позволяющие работать с большими таблицами (1 млрд.) на железе с ограниченной RAM. Т.е. когда даже индексы целиком не помещаются в память и невозможно расшардить таблицу на несколько машин. Что можно придумать кроме партицирования чтобы получить хотя бы примерно линейную зависимость производительности от количества строк? При том что даже в случае партицирования могут быть запросы читающие со всех партиций. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 13:55 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
thehilЧто можно придумать кроме партицирования чтобы получить хотя бы примерно линейную зависимость производительности от количества строк? При том что даже в случае партицирования могут быть запросы читающие со всех партиций. Спасибо.А она и так будет линейной в худшем случае. И с очень большим множителем (из-за физического ввода-вывода). Обычно стремятся сделать быстрее, чем линейную. В чем помогают, например, индексы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 13:59 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
thehil, Вы огласите задачу более детально. Пока же ничего определенного сказать нельзя. Может, любая СУБД будет одинаково плоха. А может, обычные файлы спасут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 14:00 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
И да, аналитики совсем не нужно, больше на OLTP похоже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 14:00 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
Производительность не будет линейной хотя бы из за того что при небольшом количестве записей индексы влазят в память, при большом - уже ничего не влазит. Доступ к строкам примерно равномерный, нету распределения по времени. Большинство запросов по ПК, часть - по другим индексированным полям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 14:03 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
thehilПроизводительность не будет линейной хотя бы из за того что при небольшом количестве записей индексы влазят в память, при большом - уже ничего не влазит.Да, по достижении некоторого порога будет скачок, но за ним картина опять будет той же (с индексом - логарифмическйи рост, без индекса - линейный). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 14:11 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
miksoftthehilПроизводительность не будет линейной хотя бы из за того что при небольшом количестве записей индексы влазят в память, при большом - уже ничего не влазит.Да, по достижении некоторого порога будет скачок, но за ним картина опять будет той же (с индексом - логарифмическйи рост, без индекса - линейный). Это и понятно, цель - преодолеть скачок. Мой первый вариант - партицирование, тут можно надеятся на примерно одинаковою производительность при любом числе строк для запросов по ключу партицирования. Но для остальных запросов будет только хуже. Нужны ещё варианты. Причем бесплатные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 14:15 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
А партиционирование где бесплатное? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 14:18 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
thehilЭто и понятно, цель - преодолеть скачок.Никак не преодолете. Либо физический ввод/вывод не нужен (нужные данные есть в ОП), либо нужен. Во втором случае совсем другие времена. Максимум, что в этой ситуации поможет, имхо: 1) правильный алгоритм кэширования, чтобы для наиболее критичных по времени запросов была выше вероятность обойтись данными в ОП. 2) правильное использование индексов и других механизмов СУБД, позволяющие минимизировать физический ввод/вывод. И не вовсе не факт, что партиционирование тут поможет. Пока не описана четко задача - можно теоретизировать бесконечно. Оптимизировать можно только частный случай. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 14:24 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
В случае Oracle, партишионирование поддерживает только EE - это сотни тысяч долларов на один сервер. С DB2 аналогично. Postgres? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 14:34 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
Victor Metelitsa, Да PostgreSQL поддерживает, да и на крайний случай MySQL тоже может. Насчет подробнестей - уточните что вы ещё хотите услышать? Есть отностительно слабый сервер, из железа больше ничего. Есть таблица с миллионами строк, хочется чтобы разростание до миллиардов не привело к заметному ухудшению времени отклика. Апп сервер на той же машине. Запросов не много, до нескольких в секунду. Запросы элементарные: дай/удали/измени строку по id в основном (80%), немного запросов по другим полям из этой же таблицы, использующие индекс (10%), есть несколько джойнов с такой же большой таблицей по id. Везде индексы и на небольших объёмах данных отклик устраивает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 14:43 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
thehil , А про нелинейную зависимость в OLTP от размера таблицы это вы тестами определили или предположили? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 14:45 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
Была мысль насчет шардинга mongodb на одной машине, но походу это гиблое дело. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 14:45 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
нелинейную зависимость в OLTP, Предположин, да и люди выше подтвердили. Пока всё в памяти - логарифмически, как только не влазит - должно хуже. Сейчас попробую провести тест в условиях ограниченной памяти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 14:47 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
thehilЗапросов не много, до нескольких в секунду.Ну тут и с дисковыми чтениями ничего страшного не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 14:47 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
thehilVictor Metelitsa, Да PostgreSQL поддерживает, да и на крайний случай MySQL тоже может. Насчет подробнестей - уточните что вы ещё хотите услышать? Есть отностительно слабый сервер, из железа больше ничего. Есть таблица с миллионами строк, хочется чтобы разростание до миллиардов не привело к заметному ухудшению времени отклика. Апп сервер на той же машине. Запросов не много, до нескольких в секунду. Запросы элементарные: дай/удали/измени строку по id в основном (80%), немного запросов по другим полям из этой же таблицы, использующие индекс (10%), есть несколько джойнов с такой же большой таблицей по id. Везде индексы и на небольших объёмах данных отклик устраивает. Сколько ОЗУ? Какая СУБД? Первые 2-3 уровня индекса будут закэшированы. Партиционирование это фактически ещё один уровень индекса. Здесь удобство бывает в том, что с партициями можно работать как с обычными таблицами и переносить их между тейблспейсами и соотвественно на другие СХД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 14:49 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
miksoft, Возможно. Но в любом случае чтение с диска заметно медленнее чем из памяти. В случае с партицирование есть шанс выделить наиболее используемые данные в одну партицию и тогда шанс попадание в кеш индекса для этой партиции должен быть выше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 14:51 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
thehilнелинейную зависимость в OLTP, Предположин, да и люди выше подтвердили. Пока всё в памяти - логарифмически, как только не влазит - должно хуже. Сейчас попробую провести тест в условиях ограниченной памяти. Если подтвердиться то только шардинг, кластер или добавлять памяти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 14:52 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
thehilmiksoft, Возможно. Но в любом случае чтение с диска заметно медленнее чем из памяти. В случае с партицирование есть шанс выделить наиболее используемые данные в одну партицию и тогда шанс попадание в кеш индекса для этой партиции должен быть выше. Попробуйте "провести тест в условиях ограниченной памяти." и если будут ухудшения, то попробуйте от них избавиться "выделить наиболее используемые данные в одну партицию и тогда шанс попадание в кеш индекса для этой партиции должен быть выше.". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 14:54 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
Сколько ОЗУ? Какая СУБД?Сколько ОЗУ? Какая СУБД? Первые 2-3 уровня индекса будут закэшированы. Партиционирование это фактически ещё один уровень индекса. Здесь удобство бывает в том, что с партициями можно работать как с обычными таблицами и переносить их между тейблспейсами и соотвественно на другие СХД. Сейчас PostgreSQL, но возможно поменять на абсолютно любую бесплатную. ОЗУ может меняться, т.к. приложение целиком с базой ставится на клиентский сервер. Давайте предположим что минимум 4 Gb ОЗУ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 14:54 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
нелинейную зависимость в OLTPthehilнелинейную зависимость в OLTP, Предположин, да и люди выше подтвердили. Пока всё в памяти - логарифмически, как только не влазит - должно хуже. Сейчас попробую провести тест в условиях ограниченной памяти. Если подтвердиться то только шардинг, кластер или добавлять памяти. К сожалению все эти варианты сразу отпадают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 14:55 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
thehilmiksoft, Возможно. Но в любом случае чтение с диска заметно медленнее чем из памяти.Пока не озвучены четкие цифры вида "такой-то SQL-запрос на таких-то данных отрабывает за X секунд, а допустимо не более чем за Y секунд в Z% случаев" ваши фразы типа "заметно медленнее" - ни о чем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 14:55 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
Victor MetelitsaВ случае Oracle, партишионирование поддерживает только EE - это сотни тысяч долларов на один сервер. С DB2 аналогично. Partition Views есть в любой оракловой редакции http://docs.oracle.com/cd/A57673_01/DOC/server/doc/A48506/partview.htm#351 в постгрес взрослого партитионинга нет, но есть те же самые Partition Views ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 14:58 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
thehilЕсть отностительно слабый сервер, из железа больше ничего. Есть таблица с миллионами строк, хочется чтобы разростание до миллиардов не привело к заметному ухудшению времени отклика. Апп сервер на той же машине. Запросов не много, до нескольких в секунду. Запросы элементарные: дай/удали/измени строку по id в основном (80%), немного запросов по другим полям из этой же таблицы, использующие индекс (10%), есть несколько джойнов с такой же большой таблицей по id. Везде индексы и на небольших объёмах данных отклик устраивает. Загрузите тестовыми данными, да посмотрите. Лично мне кажется, что при такой абстрактной постановке и с миллиардами записей будет терпимо работать (причём даже без партишионирования, но при наличии подходящих индексов). Вот бекапы делать - это да... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 15:01 |
|
||
|
Большая таблица, мало RAM
|
|||
|---|---|---|---|
|
#18+
Yo.!Victor MetelitsaВ случае Oracle, партишионирование поддерживает только EE - это сотни тысяч долларов на один сервер. С DB2 аналогично. Partition Views есть в любой оракловой редакции http://docs.oracle.com/cd/A57673_01/DOC/server/doc/A48506/partview.htm#351 А... Я уже забыл про эту фичу (в DB2 такое можно также на любых версиях) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2012, 15:09 |
|
||
|
|
start [/forum/topic.php?fid=35&msg=37622185&tid=1552593]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
38ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
2ms |
| others: | 240ms |
| total: | 389ms |
| 0 / 0 |
