Здравствуйте, adontz, Вы писали:
A>Я сделал индекс наоборот A>
CREATE CLUSTERED INDEX [Test/IX/AddedErased] ON [Test]([Added] ASC, [Erased] ASC);
A>вместо A>
CREATE CLUSTERED INDEX [Test/IX/ErasedAdded] ON [Test]([Erased] ASC, [Added] ASC);
A>и это заметно помогло: 12 секунд вместо 19.
Есть мнение, что это произошло из-за изменения плана запроса и каких-то особенностей внутренней работы сервера. Я не вижу в новом индексе никаких преимуществ над старым.
A>Честно говоря, я очень удивлён, что SQL Server читает все строки до начала диапазона.
Он всегда так делал — в индексах нет такой информации, которая позволила бы обойтись без чтения всех предыдущих строк.
A>И тут ничего не поделаешь, наверное, потому что в плане запроса 99% clustered index seek.
Не, можно кое-что придумать.
Здесь главная проблема в том, что сам индекс очень большой — около 900 Мб. Если он полностью загружен в память, то запрос выполнится быстро, а если не загружен, то потребуется много дополнительного времени для его чтения с диска.
Чтобы ускорить работу нужно уменьшить объём данных, которые должны быть прочитаны с диска. Индексы можно задать так:
ALTER TABLE [Test] ADD CONSTRAINT [Test/PK/ID] PRIMARY KEY CLUSTERED ([ID] ASC);
CREATE INDEX [Test/IX/ErasedAdded] ON [Test] ([Erased] ASC, [Added] ASC);
А запрос немного переписать:
SELECT [Test].[ID], [Test].[Text], [Test].[Added]
FROM
(SELECT [ID], [Added], ROW_NUMBER() OVER (ORDER BY [Added] ASC) AS [Index]
FROM [Test] WHERE [Erased] = 0) [OrderedTest]
LEFT JOIN
[Test] ON [OrderedTest].[ID] = [Test].[ID]
WHERE
[Index] BETWEEN 899000 AND 900000
ORDER BY
[Index]
В этом случае размер индекса [Test/IX/ErasedAdded] будет всего около 16 Мб. А новый запрос позволяет серверу выбрать ID нужных записей, используя только этот индекс (со старым запросом оптимизатор Express'a не справился). Когда ID записей найдены, в основную таблицу делается очень небольшое количество обращений — столько, сколько возвращается записей. В худшем случае это по одной странице размером 8К для каждой из тысячи записей. Т.е. для выполнения всего запроса потребуется прочитать с диска не более 24 Мб.
Тут, правда, возникнут проблемы, если нужно возвращать намного больше 1000 записей, и они разбросаны по всей таблице. Но это уже другая история.
Re[7]: [SQL Server Compact] Можно ли использовать?
Здравствуйте, Ocenochka, Вы писали:
A>>То есть задача эффективной фильтрации успешно решена. O> Задача фильтрации может и решена, а вот задача быстрого рендеринга html-страницы, выводящей часть данных такого запроса — не решена.
WITH
[OrderedTest] AS
(
SELECT
[ID],
[Text],
[Added],
ROW_NUMBER() OVER (ORDER BY [Added] ASC) AS [Index]
FROM
[Test]
WHERE
([Erased] = 0)
)
SELECT
[ID],
[Text],
[Added]
FROM
[OrderedTest]
WHERE
([Index] BETWEEN 10000 AND 11000)
ORDER BY
[Added]
Инициализация БД. Имеем миллион уникальных записей.
--------------------------------------------------------------------------------
DROP TABLE [Test];
--------------------------------------------------------------------------------
GO
--------------------------------------------------------------------------------
CREATE TABLE [Test]
(
[ID] INT NOT NULL IDENTITY,
[Text] NVARCHAR(400) NOT NULL,
[Erased] BIT NOT NULL,
[Added] DATETIME NOT NULL
);
--------------------------------------------------------------------------------
GO
--------------------------------------------------------------------------------
ALTER TABLE [Test] ADD CONSTRAINT [Test/PK/ID] PRIMARY KEY NONCLUSTERED ([ID] ASC);
CREATE CLUSTERED INDEX [Test/IX/ErasedAdded] ON [Test]([Erased] ASC, [Added] ASC);
--------------------------------------------------------------------------------
DECLARE @Index INT
DECLARE @String NVARCHAR(400);
SET @Index = 0;
WHILE (@Index < 1000000)
BEGIN
SET @String =
CAST(NEWID() AS NVARCHAR(100)) +
CAST(NEWID() AS NVARCHAR(100)) +
CAST(NEWID() AS NVARCHAR(100)) +
CAST(NEWID() AS NVARCHAR(100)) +
CAST(NEWID() AS NVARCHAR(100)) +
CAST(NEWID() AS NVARCHAR(100)) +
CAST(NEWID() AS NVARCHAR(100)) +
CAST(NEWID() AS NVARCHAR(100)) +
CAST(NEWID() AS NVARCHAR(100)) +
CAST(NEWID() AS NVARCHAR(100)) +
CAST(NEWID() AS NVARCHAR(100));
INSERT INTO
[Test]([Text], [Erased], [Added])
VALUES (@String, CASE WHEN RAND() > 0.1 THEN 0 ELSE 1 END, GETDATE())
SET @Index = @Index + 1;
END
У меня получилось 900077 неудалённых записей и 99923 удалённых.
Запрос (обычный винчестер, никакого рейда, сервер ограничен 2Гб памяти)
16 секунд (100%) - SELECT * FROM [Test]
12 секунд ( 75%) - SELECT * FROM [Test] WHERE [Erased] = 0 ORDER BY [Added]
Запрос (обычный винчестер, никакого рейда, сервер ограничен 256Мб памяти)
38 секунд (100%) - SELECT * FROM [Test]
20 секунд ( 53%) - SELECT * FROM [Test] WHERE [Erased] = 0 ORDER BY [Added]
То есть задача эффективной фильтрации успешно решена.
Вот если у вашего провайдера диски веб-сервера быстрее дисков SQL сервера, тогда я не знаю что делать кроме как сменить провайдера.
Здравствуйте, Ocenochka, Вы писали:
O> Допустим у меня список ключ/поле в такой БД. Записи делаются в архаичном порядке.
Хронологический, а не архиачный.
O> Нужно получить десятую страницу по двадцать записей в каждой, отсортированных по полю. O> Придётся ли получать все записи, сортировать, а потом отсчитывать с 200-ой по 220-ую?
Здравствуйте, Ocenochka, Вы писали:
O> Вы мне лучше скажите что нужно сделать, чтобы пейджировать 500к записей в одной таблице быстрее чем за секунду на среднем железе.
Как написать запрос так, чтобы отбирались только нужные в данный момент данные, а не все подряд, уже подсказали.
Если хочется еще более лучшей отзывчивости сайта, то надо научиться пользоваться управлять клиентским кешированием, выставлять странице правильные заголовки.
При должном подходе можно добиться кеширования на всем пути прохождения страницы до клиента от прокси и кеша IIS до браузера на заданный тобою в заголовках период.
Но даже если не хочется использовать тотальное кеширование, то на этот случай клиенты шлют специальный хидер (IF-MODIFIED-SINCE), которым дают понять серверной стороне, что есть некие данные от такого-то числа. Данные с тех пор обновились или нет? Тогда остается только проверить изменения и отправить клиенту либо обновленную страницу либо выставить статус 304.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[7]: [SQL Server Compact] Можно ли использовать?
Здравствуйте, Ocenochka, Вы писали:
O>Здравствуйте, samius, Вы писали:
O>>> Я думаю, что чтение маленького файла быстрее чем запрос в другой процесс, в котором нагромождено куча всего + все равно идет работа с файлом. S>>Это ошибочное мнение в общем случае.
O> Не плохо было бы аргументировать.
Выборка по индексу может работать быстрее чем чтение всего файла в общем случае. Специально не делаю сильных утвреждений.
полагаю, adontz уже убедил в этом.
O>>> Я пробовал (без транзакционной работы) вводить файлы и скорость работы с ними была в несколько раз выше (всегда — мгновенная) даже по сравнению с простыми запросами к БД. S>>А как насчет непростых запросов к файлам?
O> Непростые запросы к файлам мне не нужны — на то они и файлы.
а как тогда по поводу простых запросов к индексированной таблице?
S>>>>Значит встает вопрос синхронизации кэша с таблицей. O>>> Конечно встает, но в нем я сложностей не вижу — раз в сутки перестраивать в моем случае допустимо. Главное — транзакционно. S>>Транзакционно и раз в сутки?
O> А что не так? Ну может раз в час... я пока не знаю сколько ресурсов на это будет уходить.
Транзакции нужны для того что бы данные в БД были согласованные. Если синхронизировать кэш раз в час, то можно считать данные кэша будут согласованы мгновение в час.
Или речь о том что бы запретить модификацию данных на время перестроения кэша?
O> Гуглил я такое уже ) И как создавать индексы я знаю. O> Вы мне лучше скажите что нужно сделать, чтобы пейджировать 500к записей в одной таблице быстрее чем за секунду на среднем железе.
Накидать adontz-у спасибов раза 4 как минимум.
Во всяком случае, полагаю что нужда в велосипедостроении отпала.
Re[8]: [SQL Server Compact] Можно ли использовать?
Здравствуйте, rameel, Вы писали:
R>Если хочется еще более лучшей отзывчивости сайта, то надо научиться пользоваться управлять клиентским кешированием, выставлять странице правильные заголовки.
R>При должном подходе можно добиться кеширования на всем пути прохождения страницы до клиента от прокси и кеша IIS до браузера на заданный тобою в заголовках период.
IIS замечательно умеет кешировать готовые страницы.
Т.е., рекомендую дополнительно ко всем предложенным решениям по оптимизации выборки из БД использовать кеширование на стороне IIS.
Если настроить кеширование для страницы целиком не представляется возможным (например, на странице отображается информация о текущем пользователе), то можно вынести таблицу, отображающую одну страницу данных в отдельный ascx-контрол. Для этого контрола настроить кеширование на нужное время и с вариацией по параметрам. Подробнее см. Caching Portions of an ASP.NET Page.
Здравствуйте, Ocenochka, Вы писали:
O>pps Проблема может показаться надуманной, типа чего там купил памяти, построил индекс и все, но: O>1. проект пока не запущен и убыточен и еще больше денег, кроме хостинга не охота на него тратить.
А тратить время на изобретение мопеда охото?
Сколько денег будет стоить место под индекс БД и сколько под файловый кэш данных?
O>2. задача интересна сама по себе, т.к. логично кэшировать редко меняющиеся данные на винте, а не запрашивать все время из БД.
А БД хранит данные на перфокартах что ли?
Если винт загружен, то он сосать будет что под БД, что под набором файлов, только под набором файлов наверняка сильнее.
Здравствуйте, Ocenochka, Вы писали:
O>Здравствуйте, samius, Вы писали:
S>>Сколько денег будет стоить место под индекс БД и сколько под файловый кэш данных? O> Дело не только в деньгах. Место на диске более дешевый ресурс уметь его использовать стратегически важно.
Стратегически важно уметь использовать то, что дорого. Например, свое время.
Кэшировать данные на диске можно, но будучи уверенным, что ты это делаешь эффективнее чем БД. Как это делает БД, ты узнать не стремишься. Результат будет печален.
O>>>2. задача интересна сама по себе, т.к. логично кэшировать редко меняющиеся данные на винте, а не запрашивать все время из БД. S>>А БД хранит данные на перфокартах что ли? S>>Если винт загружен, то он сосать будет что под БД, что под набором файлов, только под набором файлов наверняка сильнее. O> В основной БД хотя бы таблица лочиться не будет, (в нее еще регулярно идет запись).
Значит встает вопрос синхронизации кэша с таблицей.
O> Загруженность БД != загруженность винта.
Я не утверждал что они равны. Сделай доброе дело, создай индекс и разгрузи винт.
Re[3]: [SQL Server Compact] Можно ли использовать?
Здравствуйте, Ocenochka, Вы писали:
O>Здравствуйте, samius, Вы писали:
S>>Стратегически важно уметь использовать то, что дорого. Например, свое время.
O> Я свое время выделяю на обучение новым интересующим меня вещам. O> Кэширование на жестком диске и работа с inproc-БД как раз такие вещи.
Тогда начать нужно с изучения механизмов работы БД.
O> Я думаю, что чтение маленького файла быстрее чем запрос в другой процесс, в котором нагромождено куча всего + все равно идет работа с файлом.
Это ошибочное мнение в общем случае. O> Я пробовал (без транзакционной работы) вводить файлы и скорость работы с ними была в несколько раз выше (всегда — мгновенная) даже по сравнению с простыми запросами к БД.
А как насчет непростых запросов к файлам?
S>>Значит встает вопрос синхронизации кэша с таблицей.
O> Конечно встает, но в нем я сложностей не вижу — раз в сутки перестраивать в моем случае допустимо. Главное — транзакционно.
Транзакционно и раз в сутки?
O> В общем-то Вы меня почти убедили. Только я не знаю как построить индексы, чтобы они дали сравнимую с файлами скорость. Опишу более подробно: O> есть таблица: (750к записей (на самом деле)) O> в конечном итоге, мне нужно выполнить такой запрос: O>
O> select * from table
O> where erased == 0
O> order by added
O>
O>Даже такой запрос O>
O> select * from table
O> where erased == 0
O>
O>выполняется на моей (более мощной машине, чем на хостинге) 6 секунд. O>По сравнению с файлами, которые читаются мгновенно — БД, как Вы выражаетесь, сосет.
O>Подскажите как настроить БД чтобы это происходило меньше чем за секунду?
Думаю что этого должно быть достаточно.
+ paging значительно упростит время выполнения.
Re[5]: [SQL Server Compact] Можно ли использовать?
Есть сайт на хостинге.
Есть "взрослая" БД с ограниченным местом, которое уже подходит к концу.
В этой БД есть одна таблица:
{
id [int]
text [nvarchar(400)]
}
Записей в этой таблице 500.000 шт.
На сайте нужно отображает все 500к сущностей постранично. Количество страниц не ограничено никаким значение — пролистать можно все 500к.
Работает это сильно медленнее, чем хотелось бы, поскольку при выборе страницы приходится скан всей таблицы 500к.
(относительно нетехнических решений этой проблемы смотри "pps" в конце поста)
Есть место на диске, которое можно использовать (достаточное количество).
Я хотел бы использовать это место для кэширования этой большой коллекции, чтобы пейджирование работало быстрее.
Для этого я решил выгружать всю таблицу из БД и сохранять ее на диск разбивая на небольшие файлы, а при запросе N-ой страницы читать тот файл, в котором хранится N-ая страница.
Вроде вполне нормальное решение, но встала проблема транзакционной работы с файлами — создавать lock-файлы не вариант, делать примитивы синхронизации в памяти — то же (поток может умереть в процессе выполнения или сервер может быть перезапущен при превышении оперативного кэша и повиснут файлы в невалидном состоянии).
Вопрос: можно ли использовать для этой задачи SQL Server Compact и как? Если я просто запихну всю коллекцию 500к в таблицу sql compact'а, то возникнет та же проблема производительности — полный скан таблицы. Создавать несколько таблиц и разбивать всю коллекцию 500к по таблицам, в каждой из которых по 10-50к записей как-то криво, хотя в итоге это даст увеличение скорости работы.
И поскольку с Sql compact никогда не работал — не знаю как там с многопоточным доступом и транзакциями.
ps Я уже задавал похожий вопрос на этом форуме и найденным тогда решением было кэшировать всю таблицу в памяти, но теперь экспериментальным путем я выявил, что при превышении 100 МБ оперативной памяти хостер перезапускает все приложение стирая кэш, поэтому кэш живет ровно один запрос.
pps Проблема может показаться надуманной, типа чего там купил памяти, построил индекс и все, но:
1. проект пока не запущен и убыточен и еще больше денег, кроме хостинга не охота на него тратить.
2. задача интересна сама по себе, т.к. логично кэшировать редко меняющиеся данные на винте, а не запрашивать все время из БД.
03.12.10 09:38: Перенесено из '.NET'
Люблю ставить оценки.
Re[2]: [SQL Server Compact] Можно ли использовать?
Здравствуйте, samius, Вы писали:
O>>pps Проблема может показаться надуманной, типа чего там купил памяти, построил индекс и все, но: O>>1. проект пока не запущен и убыточен и еще больше денег, кроме хостинга не охота на него тратить. S>А тратить время на изобретение мопеда охото? S>Сколько денег будет стоить место под индекс БД и сколько под файловый кэш данных?
Дело не только в деньгах. Место на диске более дешевый ресурс уметь его использовать стратегически важно.
O>>2. задача интересна сама по себе, т.к. логично кэшировать редко меняющиеся данные на винте, а не запрашивать все время из БД. S>А БД хранит данные на перфокартах что ли? S>Если винт загружен, то он сосать будет что под БД, что под набором файлов, только под набором файлов наверняка сильнее.
В основной БД хотя бы таблица лочиться не будет, (в нее еще регулярно идет запись).
Загруженность БД != загруженность винта.
Люблю ставить оценки.
Re[2]: [SQL Server Compact] Можно ли использовать?
Здравствуйте, adontz, Вы писали:
O>> Есть сайт на хостинге. O>> Есть "взрослая" БД с ограниченным местом, которое уже подходит к концу.
A>Взрослая это какая?
Полноценная SQL Server 2008
A>Почему для постраничного вывода взрослой БД нужно сканировать всю таблицу?
Ну чтобы выбрать даже первую страницу нужно быть увереным, что последняя запись таблицы по условию не попадет на первую страницу вот и приходится проходить всю таблицу.
Я это так понимаю.
A>Кластерный индекс, FK+JOIN пробовали?
Нет, можно ссылку или словосочетание как гуглить?
Только есть один момент, который сразу уточню — страницы выбираются из большой таблицы не тупо как есть, а по не сложному условию и еще сортируются (в начальном посте я опустил "лишние" столбцы).
Люблю ставить оценки.
Re[4]: [SQL Server Compact] Можно ли использовать?
Здравствуйте, samius, Вы писали:
O>>Здравствуйте, samius, Вы писали:
S>>>Сколько денег будет стоить место под индекс БД и сколько под файловый кэш данных? O>> Дело не только в деньгах. Место на диске более дешевый ресурс уметь его использовать стратегически важно. S>Стратегически важно уметь использовать то, что дорого. Например, свое время.
Я свое время выделяю на обучение новым интересующим меня вещам.
Кэширование на жестком диске и работа с inproc-БД как раз такие вещи.
S>Кэшировать данные на диске можно, но будучи уверенным, что ты это делаешь эффективнее чем БД. Как это делает БД, ты узнать не стремишься. Результат будет печален.
Я думаю, что чтение маленького файла быстрее чем запрос в другой процесс, в котором нагромождено куча всего + все равно идет работа с файлом.
Я пробовал (без транзакционной работы) вводить файлы и скорость работы с ними была в несколько раз выше (всегда — мгновенная) даже по сравнению с простыми запросами к БД.
O>>>>2. задача интересна сама по себе, т.к. логично кэшировать редко меняющиеся данные на винте, а не запрашивать все время из БД. S>>>А БД хранит данные на перфокартах что ли? S>>>Если винт загружен, то он сосать будет что под БД, что под набором файлов, только под набором файлов наверняка сильнее. O>> В основной БД хотя бы таблица лочиться не будет, (в нее еще регулярно идет запись). S>Значит встает вопрос синхронизации кэша с таблицей.
Конечно встает, но в нем я сложностей не вижу — раз в сутки перестраивать в моем случае допустимо. Главное — транзакционно.
O>> Загруженность БД != загруженность винта. S>Я не утверждал что они равны. Сделай доброе дело, создай индекс и разгрузи винт.
В общем-то Вы меня почти убедили. Только я не знаю как построить индексы, чтобы они дали сравнимую с файлами скорость. Опишу более подробно:
есть таблица: (750к записей (на самом деле))
id [int] pk
text [nvarchar(400)]
erased [bit]
added [datetime]
в конечном итоге, мне нужно выполнить такой запрос:
select * from table
where erased == 0
order by added
Даже такой запрос
select * from table
where erased == 0
выполняется на моей (более мощной машине, чем на хостинге) 6 секунд.
По сравнению с файлами, которые читаются мгновенно — БД, как Вы выражаетесь, сосет.
Подскажите как настроить БД чтобы это происходило меньше чем за секунду?
Люблю ставить оценки.
Re[6]: [SQL Server Compact] Можно ли использовать?
Здравствуйте, adontz, Вы писали:
A>Инициализация БД. Имеем миллион уникальных записей.
[SKIP] A>У меня получилось 900077 неудалённых записей и 99923 удалённых.
A>Запрос (обычный винчестер, никакого рейда, сервер ограничен 2Гб памяти) A>
A>16 секунд (100%) - SELECT * FROM [Test]
A>12 секунд ( 75%) - SELECT * FROM [Test] WHERE [Erased] = 0 ORDER BY [Added]
A>
A>Запрос (обычный винчестер, никакого рейда, сервер ограничен 256Мб памяти) A>
A>38 секунд (100%) - SELECT * FROM [Test]
A>20 секунд ( 53%) - SELECT * FROM [Test] WHERE [Erased] = 0 ORDER BY [Added]
A>
A>То есть задача эффективной фильтрации успешно решена.
Задача фильтрации может и решена, а вот задача быстрого рендеринга html-страницы, выводящей часть данных такого запроса — не решена.
А если все эти данные выбирать только один раз в сутки и разбивать по файлам, то страницы будут рендериться мгновенно.
A>Вот если у вашего провайдера диски веб-сервера быстрее дисков SQL сервера, тогда я не знаю что делать кроме как сменить провайдера.
У хостера диски веб-сервера скорее всего хуже, чем диски для SQL сервера, только это дела не меняет — 12 (на моей машине ~ 6) секунд для пользователей сайта будет слишком долго.
Люблю ставить оценки.
Re[6]: [SQL Server Compact] Можно ли использовать?
Здравствуйте, samius, Вы писали:
S>>>Стратегически важно уметь использовать то, что дорого. Например, свое время. O>> Я свое время выделяю на обучение новым интересующим меня вещам. O>> Кэширование на жестком диске и работа с inproc-БД как раз такие вещи. S>Тогда начать нужно с изучения механизмов работы БД.
Спасибо за рекомендацию, приму к сведению.
O>> Я думаю, что чтение маленького файла быстрее чем запрос в другой процесс, в котором нагромождено куча всего + все равно идет работа с файлом. S>Это ошибочное мнение в общем случае.
Не плохо было бы аргументировать.
O>> Я пробовал (без транзакционной работы) вводить файлы и скорость работы с ними была в несколько раз выше (всегда — мгновенная) даже по сравнению с простыми запросами к БД. S>А как насчет непростых запросов к файлам?
Непростые запросы к файлам мне не нужны — на то они и файлы.
S>>>Значит встает вопрос синхронизации кэша с таблицей. O>> Конечно встает, но в нем я сложностей не вижу — раз в сутки перестраивать в моем случае допустимо. Главное — транзакционно. S>Транзакционно и раз в сутки?
А что не так? Ну может раз в час... я пока не знаю сколько ресурсов на это будет уходить.
O>> В общем-то Вы меня почти убедили. Только я не знаю как построить индексы, чтобы они дали сравнимую с файлами скорость. Опишу более подробно: O>> есть таблица: (750к записей (на самом деле)) O>> в конечном итоге, мне нужно выполнить такой запрос: O>>
O>> select * from table
O>> where erased == 0
O>> order by added
O>>
O>>Даже такой запрос O>>
O>> select * from table
O>> where erased == 0
O>>
O>>выполняется на моей (более мощной машине, чем на хостинге) 6 секунд. O>>По сравнению с файлами, которые читаются мгновенно — БД, как Вы выражаетесь, сосет.
O>>Подскажите как настроить БД чтобы это происходило меньше чем за секунду? S>Думаю что этого должно быть достаточно. S>+ paging значительно упростит время выполнения.
Гуглил я такое уже ) И как создавать индексы я знаю.
Вы мне лучше скажите что нужно сделать, чтобы пейджировать 500к записей в одной таблице быстрее чем за секунду на среднем железе.
Люблю ставить оценки.
Re[6]: [SQL Server Compact] Можно ли использовать?
Здравствуйте, Аноним, Вы писали:
O>>Подскажите как настроить БД чтобы это происходило меньше чем за секунду? А>Berkeley DB
Спасибо за наводку, но меня интересуетвопрос, ответ на который я не смог нагуглить сходу:
Допустим у меня список ключ/поле в такой БД. Записи делаются в архаичном порядке.
Нужно получить десятую страницу по двадцать записей в каждой, отсортированных по полю.
Придётся ли получать все записи, сортировать, а потом отсчитывать с 200-ой по 220-ую?
Люблю ставить оценки.
Re[4]: [SQL Server Compact] Можно ли использовать?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Ocenochka, Вы писали:
A>Хочу скрипт запроса без "редактирования для форума" и скрипт создания всех упоминаемых в запросе таблиц.
Люблю ставить оценки.
Re[4]: [SQL Server Compact] Можно ли использовать?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Ocenochka, Вы писали: A>Хочу скрипт запроса без "редактирования для форума" и скрипт создания всех упоминаемых в запросе таблиц.
Прошу прощения, случайно отправил пустое сообщение.
Скрипт приложу после того, как попробую Ваше решение из соседней ветки этой темы.
А то может и скрипт не нужно будет прикладывать, если запрос начнет быстро работать...
Люблю ставить оценки.
Re[8]: [SQL Server Compact] Можно ли использовать?
A>>>То есть задача эффективной фильтрации успешно решена. O>> Задача фильтрации может и решена, а вот задача быстрого рендеринга html-страницы, выводящей часть данных такого запроса — не решена.
[SKIP] A>Меньше секунды.
Большое спасибо!
Открыли глаза — я был уверен, что это невозможно.
Подскажите — чтобы понять как это работает нужно про CTE читать?
Т.е. почему так быстро получается, ведь обходить всю таблицу и сортировать ее все равно нужно, а это не может быть быстрее 'тупой' выборки данных?
Люблю ставить оценки.
Re[9]: [SQL Server Compact] Можно ли использовать?
От:
Аноним
Дата:
02.12.10 21:26
Оценка:
Здравствуйте, Ocenochka, Вы писали:
O> Открыли глаза — я был уверен, что это невозможно. O> Подскажите — чтобы понять как это работает нужно про CTE читать? O> Т.е. почему так быстро получается, ведь обходить всю таблицу и сортировать ее все равно нужно, а это не может быть быстрее 'тупой' выборки данных?
Благодаря кластерному индексу таблица уже хранится на диске в отсортированном порядке (как следствие кластерный индекс у таблицы может быть только один). Поэтому все, что нужно сделать sql серверу — это отсчитать десятитысячную запись от начала таблицы — плевое дело для mssql.
Re[10]: [SQL Server Compact] Можно ли использовать?
Здравствуйте, adontz, Вы писали:
O>> Подскажите — чтобы понять как это работает нужно про CTE читать? A>В запросе есть CTE, но это не нлавный момент.
O>> Т.е. почему так быстро получается, ведь обходить всю таблицу и сортировать ее все равно нужно A>Нет не нужно. Читайте про кластерные индексы.
У меня быстро работает без кластерных индексов.
Я ничего не менял, просто запустил запрос на своей таблице, а на таблице только кластерный индекс по id (pk) и не кластерный по added.
Причем быстро работает (1 сек) при сортировке не только по added, а по любым имеющимся столбцам на которых вообще никаких индексов нет.
Прямо магия.
Люблю ставить оценки.
Re[8]: [SQL Server Compact] Можно ли использовать?
Здравствуйте, rameel, Вы писали:
O>> Вы мне лучше скажите что нужно сделать, чтобы пейджировать 500к записей в одной таблице быстрее чем за секунду на среднем железе. R>Как написать запрос так, чтобы отбирались только нужные в данный момент данные, а не все подряд, уже подсказали. R>Если хочется еще более лучшей отзывчивости сайта, то надо научиться пользоваться управлять клиентским кешированием, выставлять странице правильные заголовки. R>При должном подходе можно добиться кеширования на всем пути прохождения страницы до клиента от прокси и кеша IIS до браузера на заданный тобою в заголовках период. R>Но даже если не хочется использовать тотальное кеширование, то на этот случай клиенты шлют специальный хидер (IF-MODIFIED-SINCE), которым дают понять серверной стороне, что есть некие данные от такого-то числа. Данные с тех пор обновились или нет? Тогда остается только проверить изменения и отправить клиенту либо обновленную страницу либо выставить статус 304.
Это я уже делаю — и кэширование на клиенте, сервере и промежуточным серверах и expired правильный выставляю и javascript с css минимизирую и в один файл их сшиваю...
Еще etag можно будет прикрутить, и в mvc 3 можно контролы еще кэшировать...
Это для меня не так сложно, как понять правильную работу с БД.
Люблю ставить оценки.
Re[8]: [SQL Server Compact] Можно ли использовать?
Здравствуйте, samius, Вы писали:
O>>>> Я думаю, что чтение маленького файла быстрее чем запрос в другой процесс, в котором нагромождено куча всего + все равно идет работа с файлом. S>>>Это ошибочное мнение в общем случае. O>> Не плохо было бы аргументировать. S>Выборка по индексу может работать быстрее чем чтение всего файла в общем случае. Специально не делаю сильных утвреждений. S>полагаю, adontz уже убедил в этом.
Убедил ) Но я ведь то же собирался все не в один файл складывать, а по частям разбивать.
Сейчас нужный мне запрос отрабатывает секунду, в то время как расчитанный, отсортированный и сохраненный по файлам он бы _мгновенно_ работал,
но тут уже слишком много проблем реализации, поэтому теперь с БД действительно проще.
O>>>> Я пробовал (без транзакционной работы) вводить файлы и скорость работы с ними была в несколько раз выше (всегда — мгновенная) даже по сравнению с простыми запросами к БД. S>>>А как насчет непростых запросов к файлам? O>> Непростые запросы к файлам мне не нужны — на то они и файлы. S>а как тогда по поводу простых запросов к индексированной таблице?
На индексы место в БД нужно, а его нет. Хотя с запросами adontz'а я готов и место докупить )
Я думал придется часть полей всех записей дублировать (в кластерном индексе) для быстрого запроса, но как видно это не нужно.
S>>>>>Значит встает вопрос синхронизации кэша с таблицей. O>>>> Конечно встает, но в нем я сложностей не вижу — раз в сутки перестраивать в моем случае допустимо. Главное — транзакционно. S>>>Транзакционно и раз в сутки? O>> А что не так? Ну может раз в час... я пока не знаю сколько ресурсов на это будет уходить. S>Транзакции нужны для того что бы данные в БД были согласованные.
Или в файлах в том случае, что я хотел.
S>Если синхронизировать кэш раз в час, то можно считать данные кэша будут согласованы мгновение в час. S>Или речь о том что бы запретить модификацию данных на время перестроения кэша?
Меня это устраивает — никто этого все равно не заметит, хотя, конечно, всегда отдавать актуальные данные лучше, если нет проблем с временем их получения.
O>> Гуглил я такое уже ) И как создавать индексы я знаю. O>> Вы мне лучше скажите что нужно сделать, чтобы пейджировать 500к записей в одной таблице быстрее чем за секунду на среднем железе. S>Накидать adontz-у спасибов раза 4 как минимум. S>Во всяком случае, полагаю что нужда в велосипедостроении отпала.
Уже накидал )
И да, действительно похоже отпала, хотя я еще детально не тестировал результаты запроса, но похоже, что все честно выбирается и сортируется как нужно.
Люблю ставить оценки.
Re[11]: [SQL Server Compact] Можно ли использовать?
Здравствуйте, Ocenochka, Вы писали:
O> У меня быстро работает без кластерных индексов.
С кластерным заработает ещё быстрее.
O> Я ничего не менял, просто запустил запрос на своей таблице, а на таблице только кластерный индекс по id (pk) и не кластерный по added.
Это значит что база сперва ищет в индексе что читать, а потом читает. Создав кластерный индекс вы увеличите производительность и сэкономите место.
O> Причем быстро работает (1 сек) при сортировке не только по added, а по любым имеющимся столбцам на которых вообще никаких индексов нет. O> Прямо магия.
Там два ORDER BY. Второй сортирует окончательную выборку, а она небольшая.
Здравствуйте, adontz, Вы писали:
O>> Причем быстро работает (1 сек) при сортировке не только по added, а по любым имеющимся столбцам на которых вообще никаких индексов нет. O>> Прямо магия. A>Там два ORDER BY. Второй сортирует окончательную выборку, а она небольшая.
Я в обоих местах меняю сортировку по столбцу без индекса — все равно отрабатывает за 1 секунду.
Ладно. Большое спасибо за помощь. Теперь буду разбираться и если вопросы возникнут, то буду создавать другую тему с более адекватным названием и содержимым.
Люблю ставить оценки.
Re[8]: [SQL Server Compact] Можно ли использовать?
Здравствуйте, adontz, Вы писали:
A>Меньше секунды.
За сколько выполнится этот же запрос, если объём доступной серверу памяти ограничить 256 Мб, а диапазон запрашиваемых записей сместить в самый конец, например, 899000-900000?
Re[9]: [SQL Server Compact] Можно ли использовать?
Здравствуйте, Sergei MO, Вы писали:
SM>За сколько выполнится этот же запрос, если объём доступной серверу памяти ограничить 256 Мб, а диапазон запрашиваемых записей сместить в самый конец, например, 899000-900000?
Здравствуйте, adontz, Вы писали:
SM>>За сколько выполнится этот же запрос, если объём доступной серверу памяти ограничить 256 Мб, а диапазон запрашиваемых записей сместить в самый конец, например, 899000-900000?
A>Примерно за столько же.
Странно, у меня он за столько же выполнятся не хочет.
[SQL Express 2008 R2]
Re[11]: [SQL Server Compact] Можно ли использовать?
Здравствуйте, Sergei MO, Вы писали:
A>>Примерно за столько же. SM>Странно, у меня он за столько же выполнятся не хочет. SM>[SQL Express 2008 R2]
Да, наврал. Сказал не подумав. Действительно больше.
Я сделал индекс наоборот
CREATE CLUSTERED INDEX [Test/IX/AddedErased] ON [Test]([Added] ASC, [Erased] ASC);
вместо
CREATE CLUSTERED INDEX [Test/IX/ErasedAdded] ON [Test]([Erased] ASC, [Added] ASC);
и это заметно помогло: 12 секунд вместо 19.
И тут ничего не поделаешь, наверное, потому что в плане запроса 99% clustered index seek. Честно говоря, я очень удивлён, что SQL Server читает все строки до начала диапазона.
