Comments 15
STRING_SPLIT здорово. А STRING_CONCAT (слияние строк с разделителем для выборки например при группировке) не появился?
+3
Шардинг? Энибади?
0
Увы нет… Сам давно жду. Но в данном направлении наметились изменения. Например тот же Stretch Database для SQL Server 2016.
0
Да лан, я прикалываюсь. Никто уже не ждет шардинга от сиквела. Уже есть куча других решений, которые это неплохо могут. Когда шардинг появится в постгресе (а они над этим хотя бы активно работают), про сиквел никто не вспомнит
-2
А можно ссылочку на шардинг для Postgres?
0
Лишь проект, основанный на нём — Greenplum
0
Был доклад на хайлоаде про будущее постгресного шардинга, я на нем присутствовал. Видосов в паблике, к сожалению, нет
0
Вроде канонические реализации string_split и string aggregate на c# существовали ещё 10 лет назад.
Причем вторая функция была примеров использования .Net расширения для SQL Server.
И шардинг можно реализовать довольно просто на sql, благодаря родному механизму репликации.
Одна проблема — больно дорого. Энтерпрайз версия сервера это $NNk на сокет.
А в кластере из N узлов получается $NNNk, а то и $NNNNk чисто на лицензии...
Причем вторая функция была примеров использования .Net расширения для SQL Server.
И шардинг можно реализовать довольно просто на sql, благодаря родному механизму репликации.
Одна проблема — больно дорого. Энтерпрайз версия сервера это $NNk на сокет.
А в кластере из N узлов получается $NNNk, а то и $NNNNk чисто на лицензии...
+1
Можно у вас спросить, как у опытного коллеги. Почему в файловой группе файлы растут не равномерно? Бывает, что один файл из 5 практически достиг верхнего лимита, а оставшиеся 4 крайне далеки от него.
0
Сложно так сразу ответить. Можно результаты запроса на почту (смотреть в профиле)?
SELECT
s.[file_id]
, file_group = d.name
, s.name
, size = CAST(s.size * 8. / 1024 AS DECIMAL(18,2))
, space_used = CAST(t.space_used * 8. / 1024 AS DECIMAL(18,2))
, free_space = CAST((s.size - t.space_used) * 8. / 1024 AS DECIMAL(18,2))
, used_percent = CAST(t.space_used * 100. / s.size AS DECIMAL(18,2))
, s.max_size
, s.growth
, s.is_percent_growth
FROM sys.database_files s
LEFT JOIN sys.data_spaces d on d.data_space_id = s.data_space_id
CROSS APPLY (
SELECT space_used = FILEPROPERTY(s.name, 'SpaceUsed')
) t
ORDER BY d.name
0
Подскажите, это много?
SELECT waiting_tasks_count
FROM sys.dm_os_wait_stats
WHERE wait_type = 'CMEMTHREAD'
AND waiting_tasks_count > 0
waiting_tasks_count
21980
SELECT spins
FROM sys.dm_os_spinlock_stats
WHERE name = 'SOS_SUSPEND_QUEUE'
AND spins > 0
spins
927979226
SQL Server 2014, 8 VCPU (VMware)
SELECT waiting_tasks_count
FROM sys.dm_os_wait_stats
WHERE wait_type = 'CMEMTHREAD'
AND waiting_tasks_count > 0
waiting_tasks_count
21980
SELECT spins
FROM sys.dm_os_spinlock_stats
WHERE name = 'SOS_SUSPEND_QUEUE'
AND spins > 0
spins
927979226
SQL Server 2014, 8 VCPU (VMware)
+1
Я бы во главу угла поставил Гигантские улучшения inmemory OLTP. В 2014 фактически это была не работающая технология из за большого объема ограничений. И почти что все эти ограничения были убраны в 2016.
Испытывал технологию на ctp3.3 на боевых данных порядка 20Гб: на многих рабочих сценариях улучшение в 100 раз!
Однако есть и ложка дегтя: по необъяснимым для меня причинам время поднятия бд — несколько часов! Например детач и аттач бд на 20Gb у меня проходит 3 часа.
При аттаче в errorlog сыпятся:
примерно раз в две секунды.
Если в релизе удастся побороть эти проблемы, то киллер-фича MSSQL 2016 — это inmemory OLTP!
Испытывал технологию на ctp3.3 на боевых данных порядка 20Гб: на многих рабочих сценариях улучшение в 100 раз!
Однако есть и ложка дегтя: по необъяснимым для меня причинам время поднятия бд — несколько часов! Например детач и аттач бд на 20Gb у меня проходит 3 часа.
При аттаче в errorlog сыпятся:
2016-03-11 17:48:38.75 spid43s Error: 41383, Severity: 16, State: 124. 2016-03-11 17:48:38.75 spid43s An internal error occurred while running the DMV query. This was likely caused by concurrent DDL operations. Please retry the query.
примерно раз в две секунды.
Если в релизе удастся побороть эти проблемы, то киллер-фича MSSQL 2016 — это inmemory OLTP!
0
Sign up to leave a comment.
SQL Server 2016 RC0