Ну в качестве бесплатного инструмента, может быть, он и хорош. Однако ведь уже есть универсальные интерфейсы, такие как DBVisualizer, поддерживающий практически любые БД и к тому же кроссплатформенный.
Судя по тому, что у кеша есть время жизни (думаю, не меньше часа, учитывая, что приходится 10 сек запрос выполнять — иначе смысле нет), на сайте интернет-магазина не очень большой товарооборот, иначе топ10 просто не будет отображать реальную ситуацию. В этом случае, целесообразно создать новую таблицу типа
Эта таблица будет содержать столько строк, сколько различных единиц товара есть в вашем магазине (могу предположить, что различных позиций меньше 100К).
Затем, на таблицу покупок можно повесить триггер, который бы обновлял(или добавлял) значение в таблицу MART.GOODSCNT. Учитывая мое предположение, что товарооборот не слишком велик, дополнительная нагрузка на базу будет незначительной.
В этом случае будет довольно просто вывести топ10 (вместо SELECT COUNT(), который вы, возможно используете)
SELECT GID FROM MART.GOODSCNT ORDER BY GCNT DESC FETCH FIRST 10 ROWS ONLY
Второй вариант, который мне приходит в голову — это создание материализованных таблиц, которые специально созданы для кеширования результатов запроса в виде таблицы. Не факт, правда, что используемая вами СУБД их поддерживает. Если такие таблицы поддерживаются, вам потребуется лишь настроить расписание их обновления.
Третий вариант — создание специализированного хранилища данных (Data warehouse) и ETL-jobs для переливки и агрегации аналитических данных. Но, в случае с небольшим интернет магазином это решение слишком дорогостоящее.
Все эти варианты можно рассматривать, если вы уверены, что текущими средствами не удается добиться прироста производительности вашего SQL запроса.
В целом, я согласен с комментарием . 10 секунд слишком много для выполнения запросов по интернет магазину. Для примера, могу сказать, что на моей практике формирование аналитического запроса с таблицей фактов >37M строк занимает 5-6 секунд.
100 лет, это же 64 в шестнадцатиричной! =) Тоже, своего рода круглая дата)
Отдельное спасибо за DB2, поздравляю и надеюсь, что когда-нибудь бюрократии при работе с бизнес-партнерами (по крайней мере в России) станет меньше (ну, хотя бы к 101 летию… Ладно уж… 101 летию в hex чтоб уж прям точно! ;) ).
Это ведь нужно для умножение очень преочень больших чисел, как я понимаю? А как можно попробовать умножить реально большие числа, а не 1000 на 2000? я что-то не очень понял. Пробовал так:
Применительно к базам данных, в русском языке прочно укоренилось написание «транзакция». В википедии (не знаю, правда, на сколько вы ей доверяете), на странице Транзакция явно присутствует предупреждение «Не следует путать с трансакция». Вас, конечно, здесь все поняли. Это просто замечание.
А если не секрет, в каких ваших учебниках употреблялось «трансакция»?
Согласен, опередили немножко.
Сами подумайте, когда перед разработчиками стоит задача оптимизировать СУБД, наверное, чтение всей строки таблицы перед ними будет маячить как красный флаг для быка.
Не уверен, что пример будет показательный (слишком много нюансов может быть), но попробовал выполнить два запроса (DB2 9.5, RHEL 5). Таблица содержит 25`000`000 строк и 12 столбцов. Индекс на ID в таблице есть.
Так обычно и есть. Есть транзакционная (оперативная) база — а есть хранилище. Мало кто нагружает оперативную базу запросами аналитики. В случае, если необходимы актуальные данные для каких-либо аналитических отчетов, организуют репликацию данных (как правило, актуализация «ноль-в-ноль» нужна не для всех отчетов, поэтому объем реплицируемых данных не очень велик).
Не знаю где там есть магнивый сплав, может быть на петельках, на которых экран держится, или внутри. А снаружи везде пластмасса, причем не самая прочная. (Говорю про T60 и T61). Сверху крышка монитора посыпана какой то крошкой, не то титановой, не то магниевой, но царапается и заляпывается от этого крышка не меньше. Корпус хлипкий, легонькое захлопывание крышки монитора привело к растрескиванию корпуса и ослабеванию фиксации (на клавиатуре лежал RSA ключ, толщиной в сантиметр примерно). Так что, уж чему-чему, а прочности ThinkPad от Lenovo не позавидуешь.
В этом «пруфлинке» они наш GSM «JSM»-ом обзывают. А GPS — JPS. «Поубывал бы хадов» =) Такое ощущение, что по телефону кто-то эти аббревиатуры диктовал.
Видимо, все-таки не все так радужно. Час назад выложил на сайт одной компании новую страницу, даже sitemap обновил для Google, но в индексе ее по-прежнему нет.
Думаю, что troorl1985 прав: все-таки остался список ресурсов которые гугл индексирует чаще и для которых Caffeine моментально обновляет индекс. Для сайтов попроще все осталось как и было.
Не согласен относительно реплик о бесполезности оконного интерфейса в браузере. Они чрезвычайно полезны во Front-end'ах, например, аналитических системах и т.д. Но там такой «кучерявости» конечно не требуется. Достаточно аскетизма ExtJS.
Но да, на просторах сети встречаются чудеса =)
Эта таблица будет содержать столько строк, сколько различных единиц товара есть в вашем магазине (могу предположить, что различных позиций меньше 100К).
Затем, на таблицу покупок можно повесить триггер, который бы обновлял(или добавлял) значение в таблицу MART.GOODSCNT. Учитывая мое предположение, что товарооборот не слишком велик, дополнительная нагрузка на базу будет незначительной.
В этом случае будет довольно просто вывести топ10 (вместо SELECT COUNT(), который вы, возможно используете)
Второй вариант, который мне приходит в голову — это создание материализованных таблиц, которые специально созданы для кеширования результатов запроса в виде таблицы. Не факт, правда, что используемая вами СУБД их поддерживает. Если такие таблицы поддерживаются, вам потребуется лишь настроить расписание их обновления.
Третий вариант — создание специализированного хранилища данных (Data warehouse) и ETL-jobs для переливки и агрегации аналитических данных. Но, в случае с небольшим интернет магазином это решение слишком дорогостоящее.
Все эти варианты можно рассматривать, если вы уверены, что текущими средствами не удается добиться прироста производительности вашего SQL запроса.
В целом, я согласен с комментарием . 10 секунд слишком много для выполнения запросов по интернет магазину. Для примера, могу сказать, что на моей практике формирование аналитического запроса с таблицей фактов >37M строк занимает 5-6 секунд.
Отдельное спасибо за DB2, поздравляю и надеюсь, что когда-нибудь бюрократии при работе с бизнес-партнерами (по крайней мере в России) станет меньше (ну, хотя бы к 101 летию… Ладно уж… 101 летию в hex чтоб уж прям точно! ;) ).
Но Dev-C++, например, говорит, что константа слишком велика. Не подскажите каким образом можно использовать такое большое число?
А если не секрет, в каких ваших учебниках употреблялось «трансакция»?
Время выполнения запроса 0.187 sec
Время выполнения запроса 0.204 sec
Сами подумайте, когда перед разработчиками стоит задача оптимизировать СУБД, наверное, чтение всей строки таблицы перед ними будет маячить как красный флаг для быка.
Не уверен, что пример будет показательный (слишком много нюансов может быть), но попробовал выполнить два запроса (DB2 9.5, RHEL 5). Таблица содержит 25`000`000 строк и 12 столбцов. Индекс на ID в таблице есть.
Время выполнения запроса: 0.235 sec
Время выполнения запроса: 0.188 sec
Думаю, что troorl1985 прав: все-таки остался список ресурсов которые гугл индексирует чаще и для которых Caffeine моментально обновляет индекс. Для сайтов попроще все осталось как и было.