Вход | Регистрация


1С:Предприятие ::

Метки: 

Максимальный объем базы

Я
   мистер игрек
 
23.01.18 - 06:37
6. 500-1000 гига50% (3)
3. 50-100 гига17% (1)
7. Больше 1- терабайта17% (1)
8. свое17% (1)
1. до 20 гига0% (0)
2. 20-50 гига0% (0)
4. 100-250 гига0% (0)
5. 250-500 гига0% (0)
Всего мнений: 6

На СКЛ сервере уже достиг 500 гига. Терпимо или что то надо делать?
Как у вас обстоять дела?
 
 
   мистер игрек
 
1 - 23.01.18 - 06:37
так

6. 500-1000 гига
   mehfk
 
2 - 23.01.18 - 06:39
   rphosts
 
3 - 23.01.18 - 06:47
(0) если данные все нужны - ничего не делай, если в базе к примеру 10 лет и реально нужны только последние 3 года - отрежь первые 5 лет (свёртка)
   мистер игрек
 
4 - 23.01.18 - 06:49
(3) Базе всего 3 года
   goleaff2006
 
5 - 23.01.18 - 06:49
5 ТБ полет нормальный
   rphosts
 
6 - 23.01.18 - 06:50
(5) можно спросить что за конфигурация и что за контора?
   1Снег
 
7 - 23.01.18 - 06:51
При росте больше 600Gb скорость работы с базой становится некомфортной, делает свертку обработкой
http://catalog.mista.ru/public/139651/

6. 500-1000 гига
   rphosts
 
8 - 23.01.18 - 06:51
(4)если внутри базы блобы не храните - да пусть так, в чем вопрос.
   rphosts
 
9 - 23.01.18 - 06:52
(7) а почему 600 а не 400 или 1024?
   1Снег
 
10 - 23.01.18 - 06:53
(9) наверно это связано с мощностью сервера :)
 
 Рекламное место пустует
   мистер игрек
 
11 - 23.01.18 - 06:56
(5) Сдается мне у вас сет супермаркетов. И чеки храните в базе?
   rphosts
 
12 - 23.01.18 - 07:04
(10) сервера разные бывают
   Зуекщмшср
 
13 - 23.01.18 - 07:22
(11) Да можно в базе и картинки товаров хранить в хорошем качестве, тогда и сети супермаркетов для этого не надо.
Объем базы сейчас уже не показатель.
   rphosts
 
14 - 23.01.18 - 07:37
(13)и плевать в колодец можно и запросы в цикле тоже можно но вот нужно-ли?
   dk
 
15 - 23.01.18 - 07:45
Но к терабайту резать будем

6. 500-1000 гига
   мистер игрек
 
16 - 23.01.18 - 07:47
(15) Сакральные причины?
   dk
 
17 - 23.01.18 - 07:51
больше психологические и скорость закачки копии этой базы в другой филиал по инету
   lodger
 
18 - 23.01.18 - 08:19
зачем вы храните блобы в рабочем экземпляре базы?
   baclazhan
 
19 - 23.01.18 - 09:13
Нужно смотреть по размерам таблиц и количествам обращений к ним.
Если часто используемая таблица больше 600 ГБ, то можно уже и порезать её. А объём всей базы не показатель к каким-либо действиям.

8. свое
   rs_trade
 
20 - 23.01.18 - 09:17
(5) пока летит, нормально. а как упадет, замучаетесь поднимать. ахах.
   rozer76
 
21 - 23.01.18 - 09:18
51гб, самописка, 3 года, 200 юзеров... пока летим ровно

3. 50-100 гига
   ptiz
 
22 - 23.01.18 - 09:19
Было до свертки 1.3Тб.
Всё-таки размер имеет значение, когда запросы сваливаются в скан таблиц. И бэкапы делать неудобно. И копию для тестов разворачивать - неудобно.
После свертки маленькая стала - 500гб.
Лишних данные нет, всё почищено что можно.

7. Больше 1- терабайта
   ptiz
 
23 - 23.01.18 - 09:20
SSD - обязательно. На hdd 15к база помирала когда достигла 400гб.
   Serg_1960
 
24 - 23.01.18 - 09:21
"зачем вы храните блобы в рабочем экземпляре базы?", sorry, навеяло: автор не уточнил о каких базах речь и, имхо, без этого вопрос - не вопрос.
"О чем этот фильм? Да ни о чем!"(цы)
Все так привыкли к типовых конфигурациям, к вопросам "по умолчанию" по типовым конфигурациям, что многие делают круглые глаза, глядя на банальные электронные архивы документации.
   ptiz
 
25 - 23.01.18 - 09:22
(0) А какая конфигурация у вас? И какие таблицы самые большие?
   rs_trade
 
26 - 23.01.18 - 09:24
(23) ССД что бы табле сканы быстрее отрабатывали? Попробуйте код получше писать.
   ptiz
 
27 - 23.01.18 - 09:25
(26) Обычные формы. Список в журнале документов - запрос формируется платформой. Сваливается в скан. Как предлагаете его переписать?
   rphosts
 
28 - 23.01.18 - 09:27
(24) пока ни разу в жизни не встречал реальных причин хранить блобы в базе.
   ptiz
 
29 - 23.01.18 - 09:27
+
ну и SSD не для сканов, а для любой работы, когда вводится по 15 тыс накладных в день.
   rphosts
 
30 - 23.01.18 - 09:27
(27)не обычные а старые как дерьмо мамонта
   rs_trade
 
31 - 23.01.18 - 09:28
(27) добавить индексов что бы без сканов обходилось. если нельзя изменить запрос.
   ptiz
 
32 - 23.01.18 - 09:38
(31) К сожалению, не помогло
Спецам SQL. Тормоза в списке документов (обычные формы, 8.2, SQL)

Решили сменой режима совместимости с 8.1 на 8.2. Списки победили, но 80% остальных запросов стали медленнее. Некоторые практически перестали работать - пришлось переписать. Но по производительности 8.1 догнать всё равно не удалось.
   rs_trade
 
33 - 23.01.18 - 09:42
(32) Открыл план запроса и тут же закрыл. Он же на русском. Как вы его читаете???
 
 



Список тем форума
Рекламное место пустует Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует