Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Как лучше организовать вставку записей?  [new]
wizzard2009
Member

Откуда: Москва
Сообщений: 19
Есть таблица с результатами поиска тура.
Каждая строка этой таблицы рассчитывается в зависимости от исходных
параметров (даты тура, количества взрослых, детей, их возраста и т.д.).
На выходе получаем: варианты проживания (номер, размещение, стоимость и нек. другие параметры).
Таблица рассчитывается в реальном времени. Сначала производится расчет,
потом запись в таблицу результатов.
Проблема вот в чем: если 2 пользователя одновременно ищут 1 и тот же тур,
то нужно предусмотреть способ, благодаря которому писать 2 строки с одинаковым результатом
станет невозможным. Как я вижу выход из данной ситуации:
1. Предрасчет. Прогнать все возможные варианты входных параметров, получая выходные.
И когда пользователя интересует поиск, просто брать строки из готовой таблицы.
Вопрос: насколько это эффективно, ведь, возможно, результаты предрасчета потребуются в 20%-25% случаев,
а все остальное будет лежать мертвым грузом.
2. Перед тем, как записать очередную строку результата, проверить, а нет ли уже такой строки в базе.
3. Сделать составной индекс по всем полям, входящим в запрос, и тогда БД сама не позволит вставить дублирующуюся запись.
Методы 2 и 3 при большом объеме данных будут вызывать тормоза. При использовании составного индекса он при
каждой вставке будет перестраиваться и с увеличением объема данных все это будет безбожно тормозить.
4. Сделать md5 от всех полей входящих в строку и по ней построить индекс.
В md5 возможны коллизии. Но они маловероятны.
Какие еще могут быть мнения? Может кто-то решал подобные задачи?
17 ноя 12, 12:33    [13488363]     Ответить | Цитировать Сообщить модератору
 Re: Как лучше организовать вставку записей?  [new]
invm
Member

Откуда: Москва
Сообщений: 9825
wizzard2009
3. Сделать составной индекс по всем полям, входящим в запрос, и тогда БД сама не позволит вставить дублирующуюся запись.
С чего вдруг? По вашему любой индекс уникальный?
wizzard2009
Методы 2 и 3 при большом объеме данных будут вызывать тормоза. При использовании составного индекса он при
каждой вставке будет перестраиваться и с увеличением объема данных все это будет безбожно тормозить.
4. Сделать md5 от всех полей входящих в строку и по ней построить индекс.
В md5 возможны коллизии. Но они маловероятны.
Ага. Составной индекс будет тормозить, а по MD5 не будет. Про перестроение индекса вообще песня.

В общем, налицо незнание основ.

В вашем случае -- unique constraint и merge для занесения строки в таблицу.
17 ноя 12, 12:53    [13488389]     Ответить | Цитировать Сообщить модератору
 Re: Как лучше организовать вставку записей?  [new]
aleks2
Guest
wizzard2009
Проблема вот в чем: если 2 пользователя одновременно ищут 1 и тот же тур,
то нужно предусмотреть способ, благодаря которому писать 2 строки с одинаковым результатом
станет невозможным.

Какие еще могут быть мнения? Может кто-то решал подобные задачи?


1. Мнение такое: фигней маетесь.
2. В то время как фсе прогрессивное человечество старается изолировать одного пользователя от другого. Вы все еще экономите строки в таблице.
3. Не майтесь фигней. Пусть каждый пользователь считает и пишет НЕЗАВИСИМО и видит ТОЛЬКО СВОИ расчеты.
17 ноя 12, 13:07    [13488408]     Ответить | Цитировать Сообщить модератору
 Re: Как лучше организовать вставку записей?  [new]
wizzard2009
Member

Откуда: Москва
Сообщений: 19
invm
Ага. Составной индекс будет тормозить, а по MD5 не будет. Про перестроение индекса вообще песня.

В общем, налицо незнание основ.

В вашем случае -- unique constraint и merge для занесения строки в таблицу.


Я поэтому и спрашиваю, потому что не знаю.
Но я проводил опыты на таблицах с 40 полями.
Так вот. После 10 миллионов вставка 1 записи может занимать больше минуты.
Как раз потому, что идет перестроение индекса.
invm
unique constraint и merge

Я так понимаю, с этим в гугл.

aleks2
3. Не майтесь фигней. Пусть каждый пользователь считает и пишет НЕЗАВИСИМО и видит ТОЛЬКО СВОИ расчеты.

А по мне так фигня что рассчитывать 100 раз один и тот же расчет для каждого пользователя, вместо того, чтобы выбрать уже готовый.
17 ноя 12, 13:18    [13488427]     Ответить | Цитировать Сообщить модератору
 Re: Как лучше организовать вставку записей?  [new]
invm
Member

Откуда: Москва
Сообщений: 9825
wizzard2009
Я поэтому и спрашиваю, потому что не знаю.
https://www.sql.ru/articles/mssql/03013101indexes.shtml
wizzard2009
Но я проводил опыты на таблицах с 40 полями.
Так вот. После 10 миллионов вставка 1 записи может занимать больше минуты.
Как раз потому, что идет перестроение индекса.
Репро в студию.
wizzard2009
invm
unique constraint и merge

Я так понимаю, с этим в гугл.
MERGE (Transact-SQL)
UNIQUE Constraints

wizzard2009
aleks2
3. Не майтесь фигней. Пусть каждый пользователь считает и пишет НЕЗАВИСИМО и видит ТОЛЬКО СВОИ расчеты.

А по мне так фигня что рассчитывать 100 раз один и тот же расчет для каждого пользователя, вместо того, чтобы выбрать уже готовый.
Заведите у себя репозиторий готовых расчетов, куда пользователи самостоятельно могут заносить свои расчеты, если сочтут это нужным. Там же можете держать типовые расчеты.
17 ноя 12, 13:55    [13488498]     Ответить | Цитировать Сообщить модератору
 Re: Как лучше организовать вставку записей?  [new]
aleks2
Guest
wizzard2009
Но я проводил опыты на таблицах с 40 полями.
Так вот. После 10 миллионов вставка 1 записи может занимать больше минуты.
Как раз потому, что идет перестроение индекса.

А по мне так фигня что рассчитывать 100 раз один и тот же расчет для каждого пользователя, вместо того, чтобы выбрать уже готовый.

1. Индексы у вас неправильные.
2. Когнитивный диссонанс: 10 миллионов/100 раз один и тот же расчет для каждого пользователя = 100 000 пользователей турагенства. Охренеть.
17 ноя 12, 17:16    [13488834]     Ответить | Цитировать Сообщить модератору
 Re: Как лучше организовать вставку записей?  [new]
wizzard2009
Member

Откуда: Москва
Сообщений: 19
aleks2
2. Когнитивный диссонанс: 10 миллионов/100 раз один и тот же расчет для каждого пользователя = 100 000 пользователей турагенства. Охренеть.

Это такая форма троллинга.
Но можно и рассчитать.
Стоимость зависит от 4 факторов: питания, лечения, периода, дополнительного критерия.
Разберем пример:
Питание: 1,2,3 разовое
Лечение: с лечением, без лечения
Период: с понедельника по среду,со среды по пятницу, с пятницы до воскресенья.
Получаем 18 вариантов.
По датам. Рассчитаем, сколько дат заездов может быть набрано за год.
Получим сумму членов арифметической прогрессии от 1 до 365.
Исключаю длину заезда 1 день. Только от 2 дней.
Получаю: (1+365)/2*365 = 183*365 = 66795
Итого : 66795 * 18 = 1 202 310 строк.
Это для 1 дома отдыха.
А их на сегодняшний день 1000.
Скажешь этого не может быть?
И по статистике: идет 1000 запросов в день.
И для тебя еще конкретика. Например, вот эта база
http://www2.turtess-online.com.ua
88 милионов строк. Еще что-то нужно объяснять?
17 ноя 12, 19:14    [13489087]     Ответить | Цитировать Сообщить модератору
 Re: Как лучше организовать вставку записей?  [new]
aleks2
Guest
wizzard2009
88 милионов строк. Еще что-то нужно объяснять?

Фсего то? Не смешите.
17 ноя 12, 19:34    [13489130]     Ответить | Цитировать Сообщить модератору
 Re: Как лучше организовать вставку записей?  [new]
wizzard2009
Member

Откуда: Москва
Сообщений: 19
aleks2
Фсего то? Не смешите.

Может и фсего то, но sql сервер на такой базе долго-долго думал.
Возможно, проблема в индексах, но для меня это факт.
И потом. Хочется сохранять расчет именно для всех пользователей, дабы не считать дважды.
А высчитывать для каждого конкретно - то есть 5, 10 раз запускать те расчеты, что
возможно, уже были рассчитаны кажется неразумным решением.
17 ноя 12, 20:13    [13489195]     Ответить | Цитировать Сообщить модератору
 Re: Как лучше организовать вставку записей?  [new]
dalex1973
Member

Откуда: Польша
Сообщений: 287
1. Если версия Enterprise, то - партицинионирование таблицы + дисковый массив.
2. Предлагаю записывать всё а ночью чистить дубликаты.
18 ноя 12, 12:14    [13490451]     Ответить | Цитировать Сообщить модератору
 Re: Как лучше организовать вставку записей?  [new]
aleks2
Guest
wizzard2009
aleks2
Фсего то? Не смешите.

Может и фсего то, но sql сервер на такой базе долго-долго думал.
Возможно, проблема в индексах, но для меня это факт.
И потом. Хочется сохранять расчет именно для всех пользователей, дабы не считать дважды.
А высчитывать для каждого конкретно - то есть 5, 10 раз запускать те расчеты, что
возможно, уже были рассчитаны кажется неразумным решением.


1. Сделать, чтобы "сервер долго думал" способен любой "пЫонер". Для этого даже не нужно таблиц. Достаточно кривых мозгов.
2. Хочется вам - делайте. Чо раздувать то на пустом месте?
3. Если вы способны идентифицировать "одинаковые" результаты расчета, то какая пичалька, что раз в миллион лет два клиента обновят одну строку?
18 ноя 12, 15:33    [13490676]     Ответить | Цитировать Сообщить модератору
 Re: Как лучше организовать вставку записей?  [new]
wizzard2009
Member

Откуда: Москва
Сообщений: 19
aleks2,

Я как мыслю. Допустим, человек задает:
Хочу 2-местный номер, с даты А по дату В.
Получается следующая картина:
2-местный 1-комнатный
2-местный 2-комнатный
2-местный 2-комнатный Люкс
2-местный 2-комнатный Полулюкс

Убрал отсюда все варианты (питание, лечение и т.д.)
У меня по выборкам получается 18-20 строк на дом отдыха в среднем
на 1 один вариант проживания. Поскольку цены даны атомрные, то
стоимость надо рассчитывать для каждого варианта размещения (1 взрослый, 2 взрослых и т.д.)
И еще и в зависимости от даты.
Можно каждый расчет снабдить идентификатором, и когда клиент будет делать заказ,
вытащить по нужному идентификатору все его составляющие.
Я подозреваю, что из 1000 будет использоваться реально 10-20 штук.
И с одной стороны делать полный расчет для всей тысячи - пустая трата ресурсов.
Поэтому можно сохранять только те результаты, которые будут запрашиваться.
И если будут запросы одни и те же, то по идентификатору запроса, можно вытащить весь расчет.
Но вот когда расчета нет, 2 клиента начнут писать одинаковые строки.
Только в этом и проблема.
18 ноя 12, 20:49    [13491584]     Ответить | Цитировать Сообщить модератору
 Re: Как лучше организовать вставку записей?  [new]
aleks2
Guest
wizzard2009
Но вот когда расчета нет, 2 клиента начнут писать одинаковые строки.
Только в этом и проблема.


И чего за проблему вы тут усмотрели?

Если у вас есть идентификатор "однозначно идентифицирующий расчет" (вот ЭТО проблема), то никакой печали.

Если второй клиент попытается вставить вторую строку - его ждет отлуп. А если использовать Merge - дык и без явного отлупа можно обойтись.
19 ноя 12, 14:10    [13494544]     Ответить | Цитировать Сообщить модератору
 Re: Как лучше организовать вставку записей?  [new]
wizzard2009
Member

Откуда: Москва
Сообщений: 19
aleks2,

Вопрос как раз в том, что делать если они оба обнаружили, что данного расчета нет.
Формируется идентификатор расчета, и вставляется обеими сразу?
19 ноя 12, 16:05    [13495526]     Ответить | Цитировать Сообщить модератору
 Re: Как лучше организовать вставку записей?  [new]
aleks2
Guest
wizzard2009
aleks2,

Вопрос как раз в том, что делать если они оба обнаружили, что данного расчета нет.
Формируется идентификатор расчета, и вставляется обеими сразу?

1. "Сразу обеими" не бывает. Бывает тока "по-очереди".
2. Второй либо не вставит, либо обновит существующую.
3. Как сделаете - так и будет.
19 ноя 12, 18:48    [13496494]     Ответить | Цитировать Сообщить модератору
 Re: Как лучше организовать вставку записей?  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
wizzard2009
Так вот. После 10 миллионов вставка 1 записи может занимать больше минуты.
Как раз потому, что идет перестроение индекса.
Я боюсь вы даже не знаете что такое перестроение индекса...
19 ноя 12, 22:15    [13497134]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить