Вопрос такого рода:
У нас преобладает тематика — моделирование и научные расчёты.
Я придерживаюсь мнения, что СУБД MS SQL Server 2012 можно успешно применять для хранения данных в клиент-серверных приложениях по подобной тематике.
На сегодняшний день, наши приложения используют именно его.
Конечно, есть некоторые вопросы. Основной из них:
Файл лога транзакций растёт очень быстро (приложения моделирования пишут много данных на каждом шаге прогона модели).
Это приводит к увеличению (весьма сильному) back-up файлов.
Как избежать данной проблемы?
Как правильно избавиться от создания и сохранения Log-ов транзакций?
Имеет ли смысл полностью избавляться от него, или просто как-то ограничить рост Log-а транзакций?
Для наших задач, откат транзакции не актуален, это не банк
You cannot "turn off" the transaction log. You can switch the recovery model to Simple or Bulk-Logged during the import. You also might want to drop some of your non-clustered indexes in the destination database. This will make the import go faster.
Как быть в этом случае? Имеет ли смысл придерживаться данного совета, или есть другие решения?
ПРИМЕЧАНИЕ: Сам сервер MS SQL Server 2012 (developer edition) у нас ставится локально,
на рабочем месте разработчика-экспериментатора и работает под ОС Windows 7 (64) SP1.
Заранее благодарю ответивших!
P.S. Так как у уважаемых товарищей, которые не в теме задач моделирования и расчётов, возникает недоумение:
— Зачем в контексте поставленных задач целый MS SQL Server?
То обоснование данного выбора приведено вот здесь
Здравствуйте, AlexGin, Вы писали:
AG>Доброе время суток, уважаемые коллеги!
AG>Вопрос такого рода: AG>У нас преобладает тематика — моделирование и научные расчёты. AG>Я придерживаюсь мнения, что СУБД MS SQL Server 2012 можно успешно применять для хранения данных в клиент-серверныхприложениях по подобной тематике. AG>На сегодняшний день, наши приложения используют именно его.
AG>Конечно, есть некоторые вопросы. Основной из них: AG>- Файл лога транзакций растёт очень быстро (приложения моделирования пишут много данных на каждом шаге прогона модели). Что приводит к увеличению (весьма сильному) back-up файлов. AG>Как избежать данной проблемы? AG>Как правильно избавиться от создания и сохранения Log-ов транзакций?
Совсем избавиться не получится. Но можно поставить простую модель восстановления (Recovery model simple). Тогда файл лога транзакций будет использоваться как кольцевой буфер и иметь ограниченный размер.
Re: MS SQL Server для моделирования и научных расчётов
Здравствуйте, AlexGin, Вы писали:
AG>Файл лога транзакций растёт очень быстро (приложения моделирования пишут много данных на каждом шаге прогона модели). AG>Это приводит к увеличению (весьма сильному) back-up файлов. AG>Как избежать данной проблемы? AG>Как правильно избавиться от создания и сохранения Log-ов транзакций? AG>Имеет ли смысл полностью избавляться от него, или просто как-то ограничить рост Log-а транзакций?
Избавиться нельзя, да и смысла не имеет. Ограничить можно.
1. Почитайте про модели восстановления (recovery model), выберите подходящую.
2. Делайте бэкапы чаще, их размер станет меньше. Старые и ненужные удаляйте.
3. На промежуточных этапах расчетов вместо обычных таблиц пишите во временные. Они не увеличивают лог.
4. Подумайте о распределении данных по нескольким базам в рамках одного инстанса. (исходные данные, промежуточные, окончательные результаты и т.д.). Для каждой базы можно настроить свой режим восстановления, стратегию бэкапа и т.д.
А лучше вместо всего этого наймите грамотного DBA. Он вам все сделает.
AG>Для наших задач, откат транзакции не актуален, это не банк
Не зарекайтесь
Re: MS SQL Server для моделирования и научных расчётов
Здравствуйте, AlexGin, Вы писали:
AG>ПРИМЕЧАНИЕ: Сам сервер MS SQL Server 2012 (developer edition) у нас ставится локально, AG>на рабочем месте разработчика-экспериментатора и работает под ОС Windows 7 (64) SP1.
Это по бедности или есть на то веские причины? Централизованно и с логами, и с бэкапами проще управляться.
Re[2]: MS SQL Server для моделирования и научных расчётов
Здравствуйте, capgreen, Вы писали:
C>Совсем избавиться не получится. Но можно поставить простую модель восстановления (Recovery model simple). Тогда файл лога транзакций будет использоваться как кольцевой буфер и иметь ограниченный размер.
В настройках Свойств Базы Данных:
Это, как я понимаю, именно оно?
Re[2]: MS SQL Server для моделирования и научных расчётов
Здравствуйте, wildwind, Вы писали:
W>Избавиться нельзя, да и смысла не имеет. Ограничить можно.
W>1. Почитайте про модели восстановления (recovery model), выберите подходящую. W>2. Делайте бэкапы чаще, их размер станет меньше. Старые и ненужные удаляйте. W>3. На промежуточных этапах расчетов вместо обычных таблиц пишите во временные. Они не увеличивают лог. W>4. Подумайте о распределении данных по нескольким базам в рамках одного инстанса. (исходные данные, промежуточные, окончательные результаты и т.д.). Для каждой базы можно настроить свой режим восстановления, стратегию бэкапа и т.д.
Спасибо, уважаемый wildwind, интересные мысли!
W>А лучше вместо всего этого наймите грамотного DBA. Он вам все сделает.
AG>>Для наших задач, откат транзакции не актуален, это не банк W>Не зарекайтесь
Здесь, если есть сомнения в результатах моделирования, просто проводим эксперимент повторно.
Каждый эксперимент — это тысячи (иногда даже десятки тысяч) относительно небольших записей в определённые таблицы БД.
Re[2]: MS SQL Server для моделирования и научных расчётов
Здравствуйте, wildwind, Вы писали:
W>Это по бедности или есть на то веские причины? Централизованно и с логами, и с бэкапами проще управляться.
Есть сервер — контроллер домена (Windows Server 2012), но пока — экспериментируем на рабочем месте.
Тем более, что для каждого из исследователей — характерна своя тематика.
На будущее — возможно развернём и центральный сервер.
Re[3]: MS SQL Server для моделирования и научных расчётов
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, capgreen, Вы писали:
C>>Совсем избавиться не получится. Но можно поставить простую модель восстановления (Recovery model simple). Тогда файл лога транзакций будет использоваться как кольцевой буфер и иметь ограниченный размер.
AG>В настройках Свойств Базы Данных: AG>Image: RecoveryModel1.jpg AG>Это, как я понимаю, именно оно?
Да.
Но можно и так
ALTER DATABASE имя_базы_данных SET RECOVERY SIMPLE;
Re: MS SQL Server для моделирования и научных расчётов
Если анализ покажет, что "затык" в дисковой подсистеме, то можно попробовать разнести файлы базы данных по разным физическим дискам, если они есть, конечно.
Я как-то растащил файлы БД по трем дискам и наблюдал увеличение производительности дисковой подсистемы чуть меньше чем в три раза
Re[2]: MS SQL Server для моделирования и научных расчётов
Здравствуйте, capgreen, Вы писали:
C>Если анализ покажет, что "затык" в дисковой подсистеме, то можно попробовать разнести файлы базы данных по разным физическим дискам, если они есть, конечно. C>Я как-то растащил файлы БД по трем дискам и наблюдал увеличение производительности дисковой подсистемы чуть меньше чем в три раза
Спасибо, уважаемый capgreen, в данном случае — проблема несколько иная (скорее теоретическая):
Если (у Заказчика) возникнет вопрос, почему выбрали именно эту СУБД (здесь достоинств масса) и как ограничить рост БД,
если лог-транзакций не нужен.
Вот и прорабатываю, как ограничить рост базы, но пока (да и в обозримой перспективе) ничего в пределы не упирается
Re[3]: MS SQL Server для моделирования и научных расчётов
Здравствуйте, AlexGin, Вы писали: AG>Если (у Заказчика) возникнет вопрос, почему выбрали именно эту СУБД (здесь достоинств масса) ...
естественно возникнет,
я вот честно сказать, даже и не знаю что ответить, зачем сиквелсервер, если асид не нужен
Re[3]: MS SQL Server для моделирования и научных расчётов
AG>Вот и прорабатываю, как ограничить рост базы, но пока (да и в обозримой перспективе) ничего в пределы не упирается
Мне, вообще, кажется, что использование MS SQL-Server в задаче где не требуется поддержка целостности данных это перебор.
Тут надо что-то из NoSQL попробовать, MongoDB например.
Re[3]: MS SQL Server для моделирования и научных расчётов
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, capgreen, Вы писали:
C>>Совсем избавиться не получится. Но можно поставить простую модель восстановления (Recovery model simple). Тогда файл лога транзакций будет использоваться как кольцевой буфер и иметь ограниченный размер.
AG>В настройках Свойств Базы Данных: AG>Image: RecoveryModel1.jpg AG>Это, как я понимаю, именно оно?
Если у вас все равно получается большой лог при простой модели, то имеет дело в том, что у вас данные пишутся в рамках больших транзакций, тогда имеет смысл резать такие транзакции на куски поменьше, например вставлять или удалять не больше заданного порога за раз. (Использовать SET ROWCOUNT ... или SELECT/INSERT/DELETE TOP (N) ... )
Re[4]: MS SQL Server для моделирования и научных расчётов
Здравствуйте, capgreen, Вы писали:
C>Мне, вообще, кажется, что использование MS SQL-Server в задаче где не требуется поддержка целостности данных это перебор. C>Тут надо что-то из NoSQL попробовать, MongoDB например.
Ага. Или что-то типа HDF5 (сам не пробовал, только приглядываюсь).
_____________________
С уважением,
Stanislav V. Zudin
Re[4]: MS SQL Server для моделирования и научных расчётов
Здравствуйте, capgreen, Вы писали:
AG>>Вот и прорабатываю, как ограничить рост базы, но пока (да и в обозримой перспективе) ничего в пределы не упирается C>Мне, вообще, кажется, что использование MS SQL-Server в задаче где не требуется поддержка целостности данных это перебор. C>Тут надо что-то из NoSQL попробовать, MongoDB например.
Если я чётко представляю структуру хранимых данных, то какой мне смысл отказываться от неё в пользу этого: https://en.wikipedia.org/wiki/NoSQL
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, capgreen, Вы писали:
AG>>>Вот и прорабатываю, как ограничить рост базы, но пока (да и в обозримой перспективе) ничего в пределы не упирается C>>Мне, вообще, кажется, что использование MS SQL-Server в задаче где не требуется поддержка целостности данных это перебор. C>>Тут надо что-то из NoSQL попробовать, MongoDB например.
AG>Если я чётко представляю структуру хранимых данных, то какой мне смысл отказываться от неё в пользу этого: AG>https://en.wikipedia.org/wiki/NoSQL
AG>Вот по теме: AG>https://habrahabr.ru/post/164361
Красивая и понятная схема данных это прекрасно (лично я только за), но она не всегда способствует повышению производительности системы, хотя, определенно, способствует повышению производительности программиста
Бывают ситуации когда для повышения производительности требуется, например такая штука, как "денормализация" данных (прямое нарушение какой-либо из нормальных форм). В общем тут, как обычно, есть место для компромисов между красотой и производительность.
Re[4]: MS SQL Server для моделирования и научных расчётов
Здравствуйте, capgreen, Вы писали:
AG>>Вот и прорабатываю, как ограничить рост базы, но пока (да и в обозримой перспективе) ничего в пределы не упирается C>Мне, вообще, кажется, что использование MS SQL-Server в задаче где не требуется поддержка целостности данных это перебор.
Есть две задачи:
a) Хранение данных с известной структурой;
b) Удобная выборка данных.
Разве этого НЕдостаточно, чтобы принять к применению чт-то из реляционних СУБД?
Спорить можно скорее на тему: ORACLE vs MS SQL
C>Тут надо что-то из NoSQL попробовать, MongoDB например.
Я читал статьи наподобие этой: https://habrahabr.ru/company/ruvds/blog/324936
или этой: https://habrahabr.ru/post/152477
...и даже и небольшую практику с MongoDB имел на старом рабочем месте.
Тем не менее, для хранилища данных (если знать структуру этих данных) — что удобнее, нежели SQL
P.S. Хочу всё-таки напомнить, что СУБД — это всё-таки инструмент для решения задач хранения данных, а не задач по созданию лишнего геморроя.
Здравствуйте, AlexGin, Вы писали: AG>Есть две задачи: AG>a) Хранение данных с известной структурой; AG>b) Удобная выборка данных.
для этой задачи даже elasticsearch подходит
Re[3]: MS SQL Server для моделирования и научных расчётов
Здравствуйте, Somescout, Вы писали:
S>Здравствуйте, AlexGin, Вы писали:
AG>>Есть сервер — контроллер домена (Windows Server 2012), но пока — экспериментируем на рабочем месте.
S>Вообще на контреллер домена SQL Server ставить не рекомендуется, и, как минимум 2005 и не ставился. Подозреваю более поздние тоже.
+100500
Да, уважаемый Somescout, именно так!
Я (под всеми правами админа) пытался установить различные версии MS SQL Server 2012 (на контроллер домена),
однако, данное действие всегда сопровождалось руганью
ALTER DATABASE [mydatabase] SET RECOVERY SIMPLE
DBCC SHRINKFILE(<log_file_name_Log>)
-- В данном случае, следующая строка не актуальна:
-- ALTER DATABASE [mydatabase] SET RECOVERY FULL
Обрезание лога транзакций может привести к падению производительности, поскольку увеличение размера файла транзакций или файла данных относительно медленное мероприятие.
Для увеличения производительности полезнее поддерживать размер файлов таким, что бы его увеличение требовалось пореже. Оптимальный вариант — заранее обеспечить в файлах наличие свободного места, что бы серверу не пришлось их наращивать в процессе обработки данных.
Здравствуйте, capgreen, Вы писали:
C>Обрезание лога транзакций может привести к падению производительности, поскольку увеличение размера файла транзакций или файла данных относительно медленное мероприятие. C>Для увеличения производительности полезнее поддерживать размер файлов таким, что бы его увеличение требовалось пореже. Оптимальный вариант — заранее обеспечить в файлах наличие свободного места, что бы серверу не пришлось их наращивать в процессе обработки данных.
Здесь всё дело в том, что "бутылочное горлышко" по производительностидля систем расчёта моделей —
не в подсистеме сохранения данных через СУБД (в т.ч. и через MS SQL Server).
Так, например, если ядро расчета значений модели выдаёт нам результаты очередного шага моделирования каждые две или три секунды,
а вот поток записи данных в БД сохранит эти значения не за 100 ms, а за 200-250 ms — то при этом всё равно,
скорость сохранения данных в таблицы БД не будет являться наиболее низкопроизводительным (узким) звеном
Но, тем не менее — спасибо, уважаемый capgreen, буду знать что данный вопрос может всплыть,
если что-либо кардинально изменится в самом ядре моделирования.
Вообще, проблема в том что SQL Server пытается создать локальные группы (в SAM), которых полностью отключены на контроллере домена. Можно это обойти (если очень хочется приключений), если сначала поставить SQL Server, а затем контроллер домена. Но лучше разнести это по виртуалкам, благо начиная с Win2012 одну лицензию Standard можно использовать на двух виртуальных машинах (на одном сервере, при условии что если используется Hyper-V, то в на хосте стоит только его роль без дополнительного софта).
ARI ARI ARI... Arrivederci!
Re: MS SQL Server для моделирования и научных расчётов
Здравствуйте, bnk, Вы писали:
bnk>А зачем вам тогда вообще SQL SERVER? Почему не просто файл например?
Файлы — возможное, однако НЕ удобное решение для данного круга задач. Причины следующие:
1) Нам нужно хранить определённые структуры данных, где явно имеются определённые поля (столбцы). Выбирать набор таких структур
намного проще испльзуя привычные SQL запросы, нежели городить свои процедуры работы с файлами, тем более, что SQL имеет удобочитаемый вид.
Это особенно важно, когда в команде авторов есть как программисты, так и разработчики алгоритмов, для которых понять SQL скрипт —
намного проще, чем разобраться в кодах C/C++ (то есть в кодах самого приложения).
2) Объём хранимой информации — весьма большой, по мере проведения экспериментов, он быстро увеличивается. Таким образом, возникнет
дополнительная проблема архиварования при переносе, которая при использовании MS SQL Server решается элементарно: back-up/restore.
3) По мере исследований и доработок имитационной модели, происходит изменение структур (таблиц), изменение количества полей (столбцов).
В этом случае, подкорректировать SQL скрипт будет намного проще (и быстрее), нежели изменять в кодах проекта процедуры работы с файлом.
4) В составе MS SQL Server имеется удобная утилита — MS SQL Server Management Studio. Применяя данную утилиту, я имею возможность:
a) запрашивать — через SELECT... любые данные из любых структур, при этом сразу видеть результат выполнения данного запроса;
b) изменять — выполнив UPDATE любую запись (строку) в любой из таблиц (без сложных действий — программирования файловых процедур);
c) исследовать различные запросы, выполняемые от нашего приложения, на предмет как корректности, так и оптимизации по времени.
5) Используя MS SQL Server Management Studio, я могу оперативно создавать новые таблицы и корректировать старые, при этом в
кодах приложения может (на текущий момент) иметься только процедура выборки данных (через SELECT...), что позволяет оперативно
изменять данные для проводимых экспериментов, не производя действий, которые впоследствии могут оказаться вообще лишними.
P.S. Вся поддержка работы с БД в кодах приложения выполнена в виде программного интерфейса (aka абстрактный класс в C++).
Посему, если возникнет необходимость, изменить тип хранилища можно относительно безболезненно.
