перевод на SQL

1. deathrow92 07.04.15 11:43 Сейчас в теме
Всем привет. подскажите стоит ли переводить базу размером 5,7 гб на SQL? конфа Комплексная автоматизация 1.1 релиз 1.1.58.1 платформа 8.3
По теме из базы знаний
Ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
2. Boneman 298 07.04.15 11:45 Сейчас в теме
(1) deathrow92, а юзверов сколько ?
5. deathrow92 07.04.15 15:05 Сейчас в теме
(2) Boneman, 10 примерно когда меньше когда чуть больше в основном 10 сидят постоянно
6. Melius 07.04.15 15:13 Сейчас в теме
(5) deathrow92, телепатирую: 1 сервер до 24Гб оперативки, терминал, скорее всего без raid. Туда же хотим сервер приложений 1С и сервер sql. Не стоит.
7. deathrow92 07.04.15 15:28 Сейчас в теме
8. Melius 07.04.15 15:43 Сейчас в теме
(7) загнется очень скоро. rphost + sqlserv съедят всю память, терминал будет тупить еще больше, чем 1С.
19. oldfornit 07.04.15 17:08 Сейчас в теме
(8) Melius, и сервер 1с и СУБД замечательно ограничиваются по потреблению оперативки.
13. tarassov 112 07.04.15 16:23 Сейчас в теме
(7) deathrow92,
(5) deathrow92,

У меня похожие параметры, работает нормально - Win+Postgrsql
14. deathrow92 07.04.15 16:32 Сейчас в теме
(13) tarassov, Postgrsql есть для винды просто я далек от sql насколько помню он был только для unix?
15. Melius 07.04.15 16:49 Сейчас в теме
(14) deathrow92, есть и для win. Вот только слабо верится, что будет это жить на таких параметрах.
20. vasyak319 151 07.04.15 17:09 Сейчас в теме
(15) Melius, у меня было несколько клиентов с 4ГБ сервером на зеркале. Шикарно всё работало, причём у одного вообще было УПП. Правда это без терминала.
16. Melius 07.04.15 16:50 Сейчас в теме
(13) tarassov, как давно? Все ли на одной машине: терминал+1С+postre?
23. tarassov 112 07.04.15 17:21 Сейчас в теме
(16) Melius,
года полтора.
AppServer 1C и SQL на одной машине.
но я не использую терминал вообще. Пользователи ходят через тонкие клиенты, в т.ч не только из локальной сети, но и через 3G модемы по OpenVPN
17. alex_sh2008 4 07.04.15 16:54 Сейчас в теме
(1) deathrow92, Есть смысл если железка позволяет и raid не ниже 5
18. oldfornit 07.04.15 17:03 Сейчас в теме
(17) alex_sh2008, позвольте с Вами не согласиться. raid-5 и СУБД - это крайне несочетаемые термины. Крайне низкая скорость записи, тем более что почему-то считается, что раз пятый рэйд можно запустить на трех дисках, то на трех и надо запускать.
Нет-нет-нет! raid-1 или raid 0+1 - наш выбор.

(1) размеры Вашей базы позволяют использовать ms sql 2012 express, правда там еще заявлено ограничение по оперативной памяти, но это лично для меня мутный момент. На домашнем ноуте спокойно по 8 гигов кушает.
postgres в принципе тоже отличный выбор, но только при условии что вы умеете его готовить и не собираетесь ставить его на win-платформе. ntfs и структура хранения данных в постгресе плохо уживаются.
21. caponid 07.04.15 17:10 Сейчас в теме
(18) oldfornit, как готовить postgre - рецептов полно - подстроить под свою задачу можно без проблем.
насчет win + Postgree - тут что то определенное не могу сказать - у меня такая связка только на тестовой базе, и довольно большой (150гб) - нареканий(после настройки) пока не было.
22. vasyak319 151 07.04.15 17:12 Сейчас в теме
(18) oldfornit,
raid-5 и СУБД - это крайне несочетаемые термины. Крайне низкая скорость записи
я тоже был приверженцем этой религии, адептом которой стал лет 15 назад. Представьте моё удивление, когда оказалось, что при равном количестве дисков современные контроллеры веселее всего летают именно на raid-5.
24. oldfornit 07.04.15 17:32 Сейчас в теме
(22) vasyak319, о, Вы меня заинтересовали.
Можно увидеть какие-нибудь результаты тестирования и сравнения?
25. vasyak319 151 07.04.15 18:10 Сейчас в теме
(24) oldfornit, я вроде на ixbt смотрел, но ссылку сейчас не вспомню. По идее, должно легко гуглиться.
26. alex_sh2008 4 08.04.15 08:35 Сейчас в теме
(18) oldfornit, И к чему это все написано?
27. oldfornit 08.04.15 08:45 Сейчас в теме
28. alex_sh2008 4 08.04.15 09:02 Сейчас в теме
(27) oldfornit, Вы это не в тему написали, вопрос был о переносе с файловой в sql, а не то какой массив лучше использовать, у меня 5 лет стоял 4 дисковый Raid-5 и со своими задачами прекрасно справлялся, перешел на raid-10 только из за сильного ограничения финансирования, raid-10 по надежнее в этом плане. В большинстве своем в базах данных идет преимущественно чтение нежели запись, поэтому raid-5 предпочтительнее для баз данных, предпочтение Raid-10 отдают из за ограниченного финансирования, и из за большей надежности Raid-10 перед raid-5, но производительность в базах данных у хорошего Raid-5 до 6 дисков или raid-50 6 дисков выше чем у raid-10
29. oldfornit 08.04.15 09:18 Сейчас в теме
(28) alex_sh2008, дело в том, что в свое время я видел кучу материалов, которые упорно рассказывали, что пятый рейд для СУБД - плохо как раз скоростью записи. Вы уже второй человек, который меня в этом переубеждает. Можете дать пару-тройку ссылок на сравнительные тесты?
30. alex_sh2008 4 08.04.15 09:24 Сейчас в теме
(29) oldfornit, Я уже вам написал чем предпочтительнее для баз данных raid-5 по сравнению с raid-10 все остальное выбор каждого и переубеждать вас не вижу ни какого смысла. Каждый сам для себя определяет, что для него наиболее предпочтительнее, быстрая запись или быстрое чтение, для меня предпочтение быстрое чтение из базы данных.
Что касается ссылок на тесты, в свое время на сайте Microsoft, была статья на английском одного из разработчиков SQL сервера как оптимально подбирать дисковый массив в зависимости от планируемых задач, которые будут выполняться в базе данных.
31. vasyak319 151 08.04.15 10:38 Сейчас в теме
(30) alex_sh2008, а не могли бы вы кинуть ссылкой или хотя бы подсказать ключевые слова для поиска, чтобы поисковик не миллион результатов выдал? Тема важная, а я пока встречал только какие-то верования на эту тему (типа "Ставьте размер страйпа по-умолчанию, ибо разработчик массива всеведущ"), что мне, как атеисту, не годится.
32. alex_sh2008 4 08.04.15 11:02 Сейчас в теме
(31) vasyak319, К сожалению нет, слишком много на эту тему написано в интернете, я случайно попал на эту статью несколько лет назад, пробуйте задавать ключевые поля исключающие сравнение массивов, а акцент делайте на оптимальный массив для sql сервера. Что касается размеров страйп блоков тут тоже надо быть осторожным и настраивать под определенный задачи, как и слишком маленький так и слишком большой могут отразиться на скорости.
3. spezc 786 07.04.15 11:46 Сейчас в теме
с учетом того, что разработчики 1С рекомендуют использовать файловую базу только для разработки или для работы одного пользователя - то да. переводить стоит.
4. Bienko 212 07.04.15 13:30 Сейчас в теме
При наличии возможностей (нормального сервера, как минимум) ответ да!
9. vasyak319 151 07.04.15 15:48 Сейчас в теме
С одной стороны, файловая база смертна, но что ещё хуже - внезапно смертна. С другой стороны, бывает, что стоит себе файловая база и не падает. В общем, смотрите сами, иметь или не иметь такой гемор, как файловая база.
10. Melius 07.04.15 15:53 Сейчас в теме
(9) vasyak319, да это не так страшно, скриптов на автоархивирование предостаточно. Чаще всего на клиент-сервер переходят, когда ошибки блокировки БД выскакивают непозволительно часто. А гемора с файловой как раз меньше, не надо админить сервера как минимум.
12. vasyak319 151 07.04.15 16:01 Сейчас в теме
(10) Melius, скрипты может и есть, но если в базе сидят юзеры, то бэкапить такое - очень стрёмная лотерея. Плюс, не раз видал ничем не примечательные запросы, которые в SQL выполняются без заметной задержки, а в файловой тупят по 5-10 минут. Плюс резкое падение скорости, когда к файловой базе подключается кто-то ещё - 1С сразу отрубает кэш. Причём не врубает обратно, когда этот "кто-то ещё" отключается. Плюс местный форум пестрит топиками "Всё было хорошо, но вдруг кто-то дёрнул рубильник, пока мы сидели в файловой базе. Хэээлп!"
11. Melius 07.04.15 15:55 Сейчас в теме
Я вот тоже перешел с файловой, чтобы гемор вылечить, и вот через 8 месяцев столько сюрпризов вылетело, что успел истосковаться по файловой.
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот