Да лан, я прикалываюсь. Никто уже не ждет шардинга от сиквела. Уже есть куча других решений, которые это неплохо могут. Когда шардинг появится в постгресе (а они над этим хотя бы активно работают), про сиквел никто не вспомнит

-2

asmaster Mar 9 2016 at 21:43

А можно ссылочку на шардинг для Postgres?

Vayngarten Mar 10 2016 at 14:45

Лишь проект, основанный на нём — Greenplum

Scratch Mar 10 2016 at 18:37

Был доклад на хайлоаде про будущее постгресного шардинга, я на нем присутствовал. Видосов в паблике, к сожалению, нет

andreylartsev Mar 10 2016 at 00:19

Вроде канонические реализации string_split и string aggregate на c# существовали ещё 10 лет назад.

Причем вторая функция была примеров использования .Net расширения для SQL Server.

И шардинг можно реализовать довольно просто на sql, благодаря родному механизму репликации.

Одна проблема — больно дорого. Энтерпрайз версия сервера это $NNk на сокет.

А в кластере из N узлов получается $NNNk, а то и $NNNNk чисто на лицензии...

gotch Mar 10 2016 at 09:32

Можно у вас спросить, как у опытного коллеги. Почему в файловой группе файлы растут не равномерно? Бывает, что один файл из 5 практически достиг верхнего лимита, а оставшиеся 4 крайне далеки от него.

AlanDenton Mar 10 2016 at 11:58

Сложно так сразу ответить. Можно результаты запроса на почту (смотреть в профиле)?

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

BigD Mar 10 2016 at 13:20

Подскажите, это много?

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)

AlanDenton Mar 10 2016 at 13:27

Особых проблем с такими значениями у Вас быть не должно. Обычно тот трейс флаг советовали включать, когда количество спинлоков переваливает за 200-300 миллиардов.

BigD Mar 10 2016 at 13:31

Спасибо.

Joshua Mar 11 2016 at 17:54

Я бы во главу угла поставил Гигантские улучшения inmemory OLTP. В 2014 фактически это была не работающая технология из за большого объема ограничений. И почти что все эти ограничения были убраны в 2016.

Испытывал технологию на 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!

Show the best of all time