Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / SQL / 25 сообщений из 27, страница 1 из 2
21.06.2010, 16:23
    #36698711
Alex Bizi
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
Вопросег...

Пример:
Хочу содержать у себя в одной таблице SQL все номера паспортов скажем Kитая. Тоесть миллиард строк в таблице.
Проблема в том что если сделать один ключь то сделать SELECT на такую таблицу возьмет много времени.
После некоторых тестов понятно что делить такую таблицу на пре ключи тоже не поможет потому что седеешь пока ждешь ответа, я решил создать много маленьких, относительно, таблиц. Скажем каждая таблица будет включать в себя номера с одним и тем же началом номера пасспорта. Ну например первые 2 цифры.

Внимание Вопрос:
Как создать класс или схему классов так чтоб INSERT/SELECT делали через один класс а он там уже решал куда писать или откуда читать.

Спасибо!
...
Рейтинг: 0 / 0
21.06.2010, 16:31
    #36698729
DAiMor
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
что то странно
если вы делаете большую таблицу
и делаете индекс по полю по которому делаете запросы, например номер паспорта
то запрос должен выполнятся очень быстро, независимо от количества строк, конечно если запрос на полное соответствие

может вы покажите класс вашей таблицы, и запрос который у вас долго выполняется, а мы подскажем что не так
...
Рейтинг: 0 / 0
21.06.2010, 17:01
    #36698828
Sergo Gromov
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
А создайте глобальку, например

^PASSP(Nomer)=ВСЁ_ЧТО_ЗНАЕТЕ_ПРО_ЧЕЛОВЕЧКА

и тогда, уверяю Вас, поиск номера не зависит от количества миллиардов записей ;)
...
Рейтинг: 0 / 0
21.06.2010, 17:19
    #36698872
Alex Bizi
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
DAiMorчто то странно
если вы делаете большую таблицу
и делаете индекс по полю по которому делаете запросы, например номер паспорта
то запрос должен выполнятся очень быстро, независимо от количества строк, конечно если запрос на полное соответствие

может вы покажите класс вашей таблицы, и запрос который у вас долго выполняется, а мы подскажем что не так

Дело в том что ето все в теории. Мои тесты были сделаны на Globals а не на таблицах SQL.
Наверно вы соглситесь что если $D долго в Globals то SELECT в SQL точно меньше не будет.
...
Рейтинг: 0 / 0
21.06.2010, 17:25
    #36698885
Alex Bizi
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
Sergo GromovА создайте глобальку, например

^PASSP(Nomer)=ВСЁ_ЧТО_ЗНАЕТЕ_ПРО_ЧЕЛОВЕЧКА

и тогда, уверяю Вас, поиск номера не зависит от количества миллиардов записей ;)

Проблема в том что бегаю я не по порядку. Вот что приводит к такой задержке. Кстати по моему мнению то что Cache пишут что это не важно сколько глобалька весит, Время получения отдельной строки не изменится, это не правда. Проверено на своей базе данных.
500 с лишним гига все-таки..
...
Рейтинг: 0 / 0
21.06.2010, 17:31
    #36698903
DAiMor
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
а тут вы уже сами себе противоречите
то вы говорите про SQL, а потом вы оказывается его даже и не касались сами по глобалам шныряете, и еще неизвестно каким способом,
в данном случаем могу сказать только то что алгоритм поиска у вас неудачный.
Приведите пример вашего хранения и алгоритм поиска.
...
Рейтинг: 0 / 0
21.06.2010, 17:34
    #36698912
DAiMor
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
Alex Bizi
Дело в том что ето все в теории. Мои тесты были сделаны на Globals а не на таблицах SQL.
Наверно вы соглситесь что если $D долго в Globals то SELECT в SQL точно меньше не будет.

$D это проверка на существование данных
а select это запрос на получение данных

что между ними общего не пойму, и что значит $D долго
...
Рейтинг: 0 / 0
21.06.2010, 17:36
    #36698919
Sergo Gromov
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
Давайте без фанатизма ! Есть вариант помочь с выборкой - говорите,я могу рассказать свой вариант, без сиквельного синтаксиса
...
Рейтинг: 0 / 0
21.06.2010, 17:38
    #36698924
Alex Bizi
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
DAiMorа тут вы уже сами себе противоречите
то вы говорите про SQL, а потом вы оказывается его даже и не касались сами по глобалам шныряете, и еще неизвестно каким способом,
в данном случаем могу сказать только то что алгоритм поиска у вас неудачный.
Приведите пример вашего хранения и алгоритм поиска.

Вот пример...

Так хранятся данные:
^Глобал(Пасспорт)=Данные человека.

От Министерства внутренних дел я получаю каждий день файл с людьми которые изменили что-то в своих данных.
Тупо бегу по файлу и изменяю данные каждого человека у себя в базе данных.
...
Рейтинг: 0 / 0
21.06.2010, 17:44
    #36698942
Alex Bizi
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
Alex Bizi,

Я хочу напомнить вопрос:

Как создать класс или схему классов так чтоб INSERT/SELECT делали через один класс а он там уже решал куда писать или откуда читать.

У ковото есть ответ?
Еше раз спасибо.
...
Рейтинг: 0 / 0
21.06.2010, 17:50
    #36698954
Sergo Gromov
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
Alex BiziDAiMorа тут вы уже сами себе противоречите
то вы говорите про SQL, а потом вы оказывается его даже и не касались сами по глобалам шныряете, и еще неизвестно каким способом,
в данном случаем могу сказать только то что алгоритм поиска у вас неудачный.
Приведите пример вашего хранения и алгоритм поиска.

Вот пример...

Так хранятся данные:
^Глобал(Пасспорт)=Данные человека.

От Министерства внутренних дел я получаю каждий день файл с людьми которые изменили что-то в своих данных.
Тупо бегу по файлу и изменяю данные каждого человека у себя в базе данных.

S A=^Глобал(Пасспорт)

МОДИФИЦИРУЕМ ПЕРЕМЕННУЮ

S ^Глобал(Пасспорт)=A

ВСЁ - И НЕ НАДО БЕГАТЬ ПО ГЛОБАЛУ
...
Рейтинг: 0 / 0
21.06.2010, 17:56
    #36698971
Alex Bizi
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
Sergo GromovAlex BiziDAiMorа тут вы уже сами себе противоречите
то вы говорите про SQL, а потом вы оказывается его даже и не касались сами по глобалам шныряете, и еще неизвестно каким способом,
в данном случаем могу сказать только то что алгоритм поиска у вас неудачный.
Приведите пример вашего хранения и алгоритм поиска.

Вот пример...

Так хранятся данные:
^Глобал(Пасспорт)=Данные человека.

От Министерства внутренних дел я получаю каждий день файл с людьми которые изменили что-то в своих данных.
Тупо бегу по файлу и изменяю данные каждого человека у себя в базе данных.

S A=^Глобал(Пасспорт)

МОДИФИЦИРУЕМ ПЕРЕМЕННУЮ

S ^Глобал(Пасспорт)=A

ВСЁ - И НЕ НАДО БЕГАТЬ ПО ГЛОБАЛУ

Так то оно Так, но это медленно на больших количествах данных. Если я разделю свою базу пасспортов на:

Глобал1(Пасспорт)
Глобал2(Пасспорт)
Глобал3(Пасспорт)
...

по какой-то логике,

Будет быстрее, если данных очень много.
...
Рейтинг: 0 / 0
21.06.2010, 18:03
    #36698986
Sergo Gromov
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
кто сказал что так будет медленно ????? так или иначе - запись лежит на винте. структура М-глобала работает через блоки указателей, которые как раз строятся через несколько уровней. аналогия предложенного разделения на разные глобалы. нет разделения на глобалы - нет лишнего программного менингита.
...
Рейтинг: 0 / 0
21.06.2010, 18:10
    #36698999
Alex Bizi
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
Sergo Gromovкто сказал что так будет медленно ????? так или иначе - запись лежит на винте. структура М-глобала работает через блоки указателей, которые как раз строятся через несколько уровней. аналогия предложенного разделения на разные глобалы. нет разделения на глобалы - нет лишнего программного менингита.

Могу ли я по аналогии на ваши слова считать что если я сделаю Х таблиц или Одну таблицу с первичным ключем то ничего не изменится в смысле времени?
...
Рейтинг: 0 / 0
21.06.2010, 18:13
    #36699003
Sergo Gromov
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
Ко всему вышесказанному мною.

Данные, лежащие в индексе глобала, нет смысла искать перебором, пользуйте эти данные как индекс через $O $G $D. Другое дело данные в области значений, для ускорения поиска по таким данным или тупой перебор всех записей или создание индекса по значению. Это нижний уровень работы с данными. А какой механизм создаст индекс - программер вручную или организация индекса в таблице для SELECT - тут как удобнее клавиши тыцкать :)

Итого: тратим время при создании - выигрываем при поиске, и наоборот
...
Рейтинг: 0 / 0
21.06.2010, 18:16
    #36699011
Alex Bizi
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
Sergo GromovКо всему вышесказанному мною.

Данные, лежащие в индексе глобала, нет смысла искать перебором, пользуйте эти данные как индекс через $O $G $D. Другое дело данные в области значений, для ускорения поиска по таким данным или тупой перебор всех записей или создание индекса по значению. Это нижний уровень работы с данными. А какой механизм создаст индекс - программер вручную или организация индекса в таблице для SELECT - тут как удобнее клавиши тыцкать :)

Итого: тратим время при создании - выигрываем при поиске, и наоборот

Спасибо за ваше мнение
...
Рейтинг: 0 / 0
21.06.2010, 18:21
    #36699022
Sergo Gromov
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
Alex BiziSergo Gromovкто сказал что так будет медленно ????? так или иначе - запись лежит на винте. структура М-глобала работает через блоки указателей, которые как раз строятся через несколько уровней. аналогия предложенного разделения на разные глобалы. нет разделения на глобалы - нет лишнего программного менингита.

Могу ли я по аналогии на ваши слова считать что если я сделаю Х таблиц или Одну таблицу с первичным ключем то ничего не изменится в смысле времени?

я "по-еврейски" ...

имеем глобал ^A

он хранится в зависимости от количества индексов с использованием одного или более уровней указателей, а именно опишу два уровня

в первом уровне ссылки на ^A("A****") ^A("B****") ^A("C****") ..... ^A("Y****") ^A("Z****")

в свою очередь отдельный указатель ^A("A****") ссылается на массив таких: ^A("AA****") ^A("AB****") ^A("AC****") .... ^A("AZ****")

если М-система не видит необходимости создавать следующий уровень указателей - второй уровень ссылается сразу на РЕАЛЬНЫЕ индексы, которые прямо привязаны к данным


То есть, получение данных наперёд известного индекса проходит поиском блока указателей первого уровня (один из 32), от него - второго уровня (один из 32) и т.д. то есть дерево. Последний поинтер указывает максимум на 32 РЕАЛЬНЫХ индекса, и таковой выбор идёт на уровне М-системы. Результат SELECT-a оперирует данными из того же глобала через эти же поинтеры только на высшем уровне :)
...
Рейтинг: 0 / 0
21.06.2010, 18:36
    #36699063
Alex Bizi
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
Sergo Gromov,

Ясно, Спасибо
...
Рейтинг: 0 / 0
21.06.2010, 19:02
    #36699112
Alexey Maslov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
это медленно на больших количествах данныхЭто может быть, т.к. у большого (>100Гб) глобала может быть 4 (и более) уровней индекса в B*-дереве (точнее можно посмотреть утилитой ^Integrity - если хватит терпения :), а значит, операции выборки / вставки затрагивают бОльшее количество индексных блоков. Но вам правильно говорят: с увеличением кол-ва глобалов ситуация может лишь ухудшится.
ИМХО, стоит пойти другим путем:
- По возможности увеличить кэш глобалов, чтобы его хватало хотя бы для индексных блоков + какого-то кол-ва блоков данных. Тогда будут повторно использоваться индексные блоки, сохраненные в кэше, и несколько уменьшится кол-во физического i/o. Это, так сказать, экстенсивный путь. Может дать ускорение на 10-15%.
- Журналирование не худо бы отключить на время массированной записи в БД. Еще 20-25%. Но если используется "тень", то это не вариант.
- Пересмотреть алгоритм. Отсортированы ли записи во входном файле? Если нет, то не лучше ли сначала перегрузить файл во временный глобал (e.g. ^CacheTempPassp) с целью сортировки, а потом уже модифицировать БД, идя $Orderom по ^CacheTempPassp. Это может дать дополнительный прирост в скорости за счет лучшего использования кэша.
...
Рейтинг: 0 / 0
21.06.2010, 19:18
    #36699136
Alex Bizi
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
Alexey Maslov,

Спасибо за идеи.
Мне тут идею на счет BitMap Indexing подкинули еше...
...
Рейтинг: 0 / 0
21.06.2010, 20:46
    #36699272
Блок А.Н.
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
Я честно говоря, не вижу проблемы
да, с увеличением числа записей увеличится время доступа.
Но не в разы, а значительно меньше.
Структура таблицы (как я вижу) - очень простая.

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

А по поводу заливки данных - там еще были
$SORTBEGIN и $SORTEND
Вроде как они отключают немедленную запись данных в базу и включают сортировку в памяти.
...
Рейтинг: 0 / 0
22.06.2010, 10:10
    #36699774
MaWr
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
Блок А.Н....
да, с увеличением числа записей увеличится время доступа.
Но не в разы, а значительно меньше...
Как правильно заметил Alexey Maslov:
Alexey Maslov- По возможности увеличить кэш глобалов, чтобы его хватало хотя бы для индексных блоков + какого-то кол-ва блоков данных. Тогда будут повторно использоваться индексные блоки, сохраненные в кэше, и несколько уменьшится кол-во физического i/o. Это, так сказать, экстенсивный путь. Может дать ускорение на 10-15%.
Я наблюдал ситуацию, когда с увеличением объема базы производительность катастрофически упала. Помог только переход на другую платформу (c Win32 на Sun solaris), что как раз позволило увеличить кэш глобалов. Падение производительности произошло как раз из-за того, что в кэш перестали помещаться индексные блоки. После смены платформы производительность возросла чуть ли не на порядок.
...
Рейтинг: 0 / 0
22.06.2010, 11:15
    #36699939
Alexey Maslov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
Блок А.Н.А по поводу заливки данных - там еще были $SORTBEGIN и $SORTENDЕсли я правильно понял ТС, нужна корректировка записей таблицы, а не чистая заливка.
MaWrПосле смены платформы производительность возросла чуть ли не на порядок.Очень интересно! Дополнительный эффект мог дать переход на более мощную серверную платформу + некоторые нюансы Solaris.
Alex BiziМне тут идею на счет BitMap Indexing подкинули ешеВо-первых, BitMap Indexing не применим к IdKey. Во-вторых, его использование при индексировании полей с малой повторяемостью значений не дает большого эффекта.
В Вашем случае, ИМХО, определенный выигрыш можно получить засчет дополнительного сжатия ключа (Nomer). Это ведь последовательность букв и цифр, не так ли? Значит, путем нехитрых преобразований можно упаковать его в меньшее кол-во байт, что уменьшит объем индекса глобала, а значит, и кол-во индексных блоков.
...
Рейтинг: 0 / 0
22.06.2010, 12:46
    #36700293
Блок А.Н.
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
И все-таки не понимаю я проблемы
Миллиард это конечно много, но у нас есть таблицы с 500 000 000 записей, причем она связана с таблице в 430 000 000, и та соотвественно еще с другими, там паутина связей.

И все это крутится динамически, живет и ворочается довольно шустро (лаг в секунду вызывает кучу вопросов - почему так медленно).

Правда там сервер стоит нормальный
Но вы же тоже не на персоналке крутите?
...
Рейтинг: 0 / 0
23.06.2010, 12:32
    #36702923
MaWr
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL
Alexey Maslov
MaWrПосле смены платформы производительность возросла чуть ли не на порядок.Очень интересно! Дополнительный эффект мог дать переход на более мощную серверную платформу + некоторые нюансы Solaris.

Да, платформа тоже немаловажна. Например время создания процесса в ОС на Solaris-е значительно меньше, а архитектура приложения такая, что коннекта постоянного нет (и JOB-процессы в win полноценно не работают). Но и увеличение кэша глобалов с 1,6 до 44 Гб сыграло не последнюю роль.
...
Рейтинг: 0 / 0
Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / SQL / 25 сообщений из 27, страница 1 из 2
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]