|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
19.01.2012, 13:55
|
|||
|---|---|---|---|
|
|||
Большая таблица, мало RAM |
|||
|
#18+
Какие существуют бесплатные решения позволяющие работать с большими таблицами (1 млрд.) на железе с ограниченной RAM. Т.е. когда даже индексы целиком не помещаются в память и невозможно расшардить таблицу на несколько машин. Что можно придумать кроме партицирования чтобы получить хотя бы примерно линейную зависимость производительности от количества строк? При том что даже в случае партицирования могут быть запросы читающие со всех партиций. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 13:59
|
|||
|---|---|---|---|
Большая таблица, мало RAM |
|||
|
#18+
thehilЧто можно придумать кроме партицирования чтобы получить хотя бы примерно линейную зависимость производительности от количества строк? При том что даже в случае партицирования могут быть запросы читающие со всех партиций. Спасибо.А она и так будет линейной в худшем случае. И с очень большим множителем (из-за физического ввода-вывода). Обычно стремятся сделать быстрее, чем линейную. В чем помогают, например, индексы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 14:00
|
|||
|---|---|---|---|
Большая таблица, мало RAM |
|||
|
#18+
thehil, Вы огласите задачу более детально. Пока же ничего определенного сказать нельзя. Может, любая СУБД будет одинаково плоха. А может, обычные файлы спасут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 14:00
|
|||
|---|---|---|---|
|
|||
Большая таблица, мало RAM |
|||
|
#18+
И да, аналитики совсем не нужно, больше на OLTP похоже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 14:03
|
|||
|---|---|---|---|
|
|||
Большая таблица, мало RAM |
|||
|
#18+
Производительность не будет линейной хотя бы из за того что при небольшом количестве записей индексы влазят в память, при большом - уже ничего не влазит. Доступ к строкам примерно равномерный, нету распределения по времени. Большинство запросов по ПК, часть - по другим индексированным полям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 14:11
|
|||
|---|---|---|---|
Большая таблица, мало RAM |
|||
|
#18+
thehilПроизводительность не будет линейной хотя бы из за того что при небольшом количестве записей индексы влазят в память, при большом - уже ничего не влазит.Да, по достижении некоторого порога будет скачок, но за ним картина опять будет той же (с индексом - логарифмическйи рост, без индекса - линейный). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 14:15
|
|||
|---|---|---|---|
|
|||
Большая таблица, мало RAM |
|||
|
#18+
miksoftthehilПроизводительность не будет линейной хотя бы из за того что при небольшом количестве записей индексы влазят в память, при большом - уже ничего не влазит.Да, по достижении некоторого порога будет скачок, но за ним картина опять будет той же (с индексом - логарифмическйи рост, без индекса - линейный). Это и понятно, цель - преодолеть скачок. Мой первый вариант - партицирование, тут можно надеятся на примерно одинаковою производительность при любом числе строк для запросов по ключу партицирования. Но для остальных запросов будет только хуже. Нужны ещё варианты. Причем бесплатные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 14:18
|
|||
|---|---|---|---|
|
|||
Большая таблица, мало RAM |
|||
|
#18+
А партиционирование где бесплатное? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 14:24
|
|||
|---|---|---|---|
Большая таблица, мало RAM |
|||
|
#18+
thehilЭто и понятно, цель - преодолеть скачок.Никак не преодолете. Либо физический ввод/вывод не нужен (нужные данные есть в ОП), либо нужен. Во втором случае совсем другие времена. Максимум, что в этой ситуации поможет, имхо: 1) правильный алгоритм кэширования, чтобы для наиболее критичных по времени запросов была выше вероятность обойтись данными в ОП. 2) правильное использование индексов и других механизмов СУБД, позволяющие минимизировать физический ввод/вывод. И не вовсе не факт, что партиционирование тут поможет. Пока не описана четко задача - можно теоретизировать бесконечно. Оптимизировать можно только частный случай. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 14:34
|
|||
|---|---|---|---|
|
|||
Большая таблица, мало RAM |
|||
|
#18+
В случае Oracle, партишионирование поддерживает только EE - это сотни тысяч долларов на один сервер. С DB2 аналогично. Postgres? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 14:43
|
|||
|---|---|---|---|
|
|||
Большая таблица, мало RAM |
|||
|
#18+
Victor Metelitsa, Да PostgreSQL поддерживает, да и на крайний случай MySQL тоже может. Насчет подробнестей - уточните что вы ещё хотите услышать? Есть отностительно слабый сервер, из железа больше ничего. Есть таблица с миллионами строк, хочется чтобы разростание до миллиардов не привело к заметному ухудшению времени отклика. Апп сервер на той же машине. Запросов не много, до нескольких в секунду. Запросы элементарные: дай/удали/измени строку по id в основном (80%), немного запросов по другим полям из этой же таблицы, использующие индекс (10%), есть несколько джойнов с такой же большой таблицей по id. Везде индексы и на небольших объёмах данных отклик устраивает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 14:45
|
|||
|---|---|---|---|
Большая таблица, мало RAM |
|||
|
#18+
thehil , А про нелинейную зависимость в OLTP от размера таблицы это вы тестами определили или предположили? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 14:45
|
|||
|---|---|---|---|
|
|||
Большая таблица, мало RAM |
|||
|
#18+
Была мысль насчет шардинга mongodb на одной машине, но походу это гиблое дело. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 14:47
|
|||
|---|---|---|---|
|
|||
Большая таблица, мало RAM |
|||
|
#18+
нелинейную зависимость в OLTP, Предположин, да и люди выше подтвердили. Пока всё в памяти - логарифмически, как только не влазит - должно хуже. Сейчас попробую провести тест в условиях ограниченной памяти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 14:47
|
|||
|---|---|---|---|
Большая таблица, мало RAM |
|||
|
#18+
thehilЗапросов не много, до нескольких в секунду.Ну тут и с дисковыми чтениями ничего страшного не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 14:49
|
|||
|---|---|---|---|
|
|||
Большая таблица, мало RAM |
|||
|
#18+
thehilVictor Metelitsa, Да PostgreSQL поддерживает, да и на крайний случай MySQL тоже может. Насчет подробнестей - уточните что вы ещё хотите услышать? Есть отностительно слабый сервер, из железа больше ничего. Есть таблица с миллионами строк, хочется чтобы разростание до миллиардов не привело к заметному ухудшению времени отклика. Апп сервер на той же машине. Запросов не много, до нескольких в секунду. Запросы элементарные: дай/удали/измени строку по id в основном (80%), немного запросов по другим полям из этой же таблицы, использующие индекс (10%), есть несколько джойнов с такой же большой таблицей по id. Везде индексы и на небольших объёмах данных отклик устраивает. Сколько ОЗУ? Какая СУБД? Первые 2-3 уровня индекса будут закэшированы. Партиционирование это фактически ещё один уровень индекса. Здесь удобство бывает в том, что с партициями можно работать как с обычными таблицами и переносить их между тейблспейсами и соотвественно на другие СХД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 14:51
|
|||
|---|---|---|---|
|
|||
Большая таблица, мало RAM |
|||
|
#18+
miksoft, Возможно. Но в любом случае чтение с диска заметно медленнее чем из памяти. В случае с партицирование есть шанс выделить наиболее используемые данные в одну партицию и тогда шанс попадание в кеш индекса для этой партиции должен быть выше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 14:52
|
|||
|---|---|---|---|
Большая таблица, мало RAM |
|||
|
#18+
thehilнелинейную зависимость в OLTP, Предположин, да и люди выше подтвердили. Пока всё в памяти - логарифмически, как только не влазит - должно хуже. Сейчас попробую провести тест в условиях ограниченной памяти. Если подтвердиться то только шардинг, кластер или добавлять памяти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 14:54
|
|||
|---|---|---|---|
Большая таблица, мало RAM |
|||
|
#18+
thehilmiksoft, Возможно. Но в любом случае чтение с диска заметно медленнее чем из памяти. В случае с партицирование есть шанс выделить наиболее используемые данные в одну партицию и тогда шанс попадание в кеш индекса для этой партиции должен быть выше. Попробуйте "провести тест в условиях ограниченной памяти." и если будут ухудшения, то попробуйте от них избавиться "выделить наиболее используемые данные в одну партицию и тогда шанс попадание в кеш индекса для этой партиции должен быть выше.". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 14:54
|
|||
|---|---|---|---|
|
|||
Большая таблица, мало RAM |
|||
|
#18+
Сколько ОЗУ? Какая СУБД?Сколько ОЗУ? Какая СУБД? Первые 2-3 уровня индекса будут закэшированы. Партиционирование это фактически ещё один уровень индекса. Здесь удобство бывает в том, что с партициями можно работать как с обычными таблицами и переносить их между тейблспейсами и соотвественно на другие СХД. Сейчас PostgreSQL, но возможно поменять на абсолютно любую бесплатную. ОЗУ может меняться, т.к. приложение целиком с базой ставится на клиентский сервер. Давайте предположим что минимум 4 Gb ОЗУ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 14:55
|
|||
|---|---|---|---|
|
|||
Большая таблица, мало RAM |
|||
|
#18+
нелинейную зависимость в OLTPthehilнелинейную зависимость в OLTP, Предположин, да и люди выше подтвердили. Пока всё в памяти - логарифмически, как только не влазит - должно хуже. Сейчас попробую провести тест в условиях ограниченной памяти. Если подтвердиться то только шардинг, кластер или добавлять памяти. К сожалению все эти варианты сразу отпадают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 14:55
|
|||
|---|---|---|---|
Большая таблица, мало RAM |
|||
|
#18+
thehilmiksoft, Возможно. Но в любом случае чтение с диска заметно медленнее чем из памяти.Пока не озвучены четкие цифры вида "такой-то SQL-запрос на таких-то данных отрабывает за X секунд, а допустимо не более чем за Y секунд в Z% случаев" ваши фразы типа "заметно медленнее" - ни о чем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 14:58
|
|||
|---|---|---|---|
|
|||
Большая таблица, мало 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, 15:01
|
|||
|---|---|---|---|
|
|||
Большая таблица, мало RAM |
|||
|
#18+
thehilЕсть отностительно слабый сервер, из железа больше ничего. Есть таблица с миллионами строк, хочется чтобы разростание до миллиардов не привело к заметному ухудшению времени отклика. Апп сервер на той же машине. Запросов не много, до нескольких в секунду. Запросы элементарные: дай/удали/измени строку по id в основном (80%), немного запросов по другим полям из этой же таблицы, использующие индекс (10%), есть несколько джойнов с такой же большой таблицей по id. Везде индексы и на небольших объёмах данных отклик устраивает. Загрузите тестовыми данными, да посмотрите. Лично мне кажется, что при такой абстрактной постановке и с миллиардами записей будет терпимо работать (причём даже без партишионирования, но при наличии подходящих индексов). Вот бекапы делать - это да... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.01.2012, 15:09
|
|||
|---|---|---|---|
|
|||
Большая таблица, мало 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 такое можно также на любых версиях) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=35&mobile=1&tid=1552593]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
23ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
| others: | 263ms |
| total: | 382ms |
| 0 / 0 |
