Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
02.09.2010, 15:59
|
|||
|---|---|---|---|
очень большие объёмы данных - несколько миллионов строк и скорость обработки |
|||
|
#18+
Нормально будет если оформить обычным persistent классом? Кто нибудь работает с такими объёмами? Скажем если средняя строка примерно на 20 полей, в сумме ну пара килобайт данных (это на одну строчку). Как оно шевелится? В связи с требованием к скорости и сложной выборке имею вопрос: С какой версии Cache в таблицах появился bitmap индекс? Кто нибудь с ним работал? какие ограничения? Намного быстрее обычных индексов? Какие вообще ощущения ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.09.2010, 17:09
|
|||
|---|---|---|---|
очень большие объёмы данных - несколько миллионов строк и скорость обработки |
|||
|
#18+
Тут скорее зависит от индексов и запросов. Пусть из нескольких миллионов нужно выбрать сотню записей - при правильных индексах данные индекса будут лежать в одном-двух блоках, чтение индекса не займет много времени. Теперь данные: в один 8кб блок будет входить только 4 записи, так что чтение каждой записи - это скорее всего обращение к своему отдельному блоку, чтобы добраться до блока данных, нужно прочитать порядка 5ти блоков включая заголовочные. С учетом кэширования, я думаю, можно считать, что для чтение записи нужно прочитать два блока данных - сам блок данных и вышестоящий блок указателей, остальное будет кэшироваться. Примем время физического чтения блока за 3 мс, итого на чтение 100 записей в ОЧЕНЬ большой таблице уйдет 0.003*100*2=0.6 сек, причем будет очень слабо зависеть от размера таблицы (как только выйдет за тот размер, который можно закэшировать) Если это много, то нужно подумать, как хранить данные ближе друг к другу, например в полях данных индекса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.09.2010, 21:17
|
|||
|---|---|---|---|
очень большие объёмы данных - несколько миллионов строк и скорость обработки |
|||
|
#18+
u78С какой версии Cache в таблицах появился bitmap индекс? Кто нибудь с ним работал? какие ограничения? Намного быстрее обычных индексов? Какие вообще ощущения ? Так вроде с 5.0 они уже были... Но "работают" они если ИДшники целые числа и "ускоряют" не всезапросы, а например типа Код: plaintext Но судя по отзывам ускоряют хорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.09.2010, 21:18
|
|||
|---|---|---|---|
очень большие объёмы данных - несколько миллионов строк и скорость обработки |
|||
|
#18+
u78Нормально будет если оформить обычным persistent классом? А каким ты еще его сможешь "оформить"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.09.2010, 07:31
|
|||
|---|---|---|---|
очень большие объёмы данных - несколько миллионов строк и скорость обработки |
|||
|
#18+
Я так понимаю, битмап индексы ускоряют только работу с самим индексом, а если придется лезть в данные - то тут на порядок дольше придеться ползти до блоков с данными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.09.2010, 09:22
|
|||
|---|---|---|---|
очень большие объёмы данных - несколько миллионов строк и скорость обработки |
|||
|
#18+
Блок А.Н. , если запрос можно свести к операциям над битовыми строками - тут появляется ускорение "битмап". Просто "перебрать" записи по такому индексу боле проблематично... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=39&mobile=1&tid=1557977]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
56ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
30ms |
get tp. blocked users: |
1ms |
| others: | 216ms |
| total: | 339ms |

| 0 / 0 |
