|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
Всем привет! Подскажите, возможно ли создать CLR библиотеку на Framework 4.0 и подгрузить ее на MSSQL 2008 R2 ? Если да, то как ? С Framework 3.5 проблем нет. Цель - использовать plinq, который доступе в Framework 4.0. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.03.2013, 11:24 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
Testor1, нет ... |
|||
:
Нравится:
Не нравится:
|
|||
13.03.2013, 11:53 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
ViPRos, В MSSQL 2012 ? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.03.2013, 12:00 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
Testor1Цель - использовать plinq, который доступе в Framework 4.0.За такие "цели" постановщику задачи "светит" пожизненная дисквалификация в дворники! Додуматься заставить писать для SQL-сервера "плюшки", которые вместо серверного движка будут на этом же самом сервере выполнять недо-запросы на LINQ (хоть и Parallel) - бред редкостный... Учите SQL и T-SQL - и будет Вам счастье! Вместе с самым быстрым и даже очень параллельным (в зависимости от версии, редакции и настроек SQL-сервера) выполнением запросов к данным. Аминь! ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2013, 01:40 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
sphinx_mvTestor1Цель - использовать plinq, который доступе в Framework 4.0.За такие "цели" постановщику задачи "светит" пожизненная дисквалификация в дворники! Додуматься заставить писать для SQL-сервера "плюшки", которые вместо серверного движка будут на этом же самом сервере выполнять недо-запросы на LINQ (хоть и Parallel) - бред редкостный... Учите SQL и T-SQL - и будет Вам счастье! Вместе с самым быстрым и даже очень параллельным (в зависимости от версии, редакции и настроек SQL-сервера) выполнением запросов к данным. Аминь! Речь не идет о стандартных запросах. Иногда требуется обрабатывать данные (парсить) на уровне базы. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2013, 11:37 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
Testor1Речь не идет о стандартных запросах. Иногда требуется обрабатывать данные (парсить) на уровне базы. А пример моно? Ни и см. пост sphinx_mv... только "постановщику задачи" заменить на dbd Хотя... полноценных регулярок нехватат... Иногда встречаются такие задачи... P.S.: а парсить нуно... до того как данные ложатся в базу ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2013, 11:56 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
buserTestor1Речь не идет о стандартных запросах. Иногда требуется обрабатывать данные (парсить) на уровне базы. А пример моно? Ни и см. пост sphinx_mv... только "постановщику задачи" заменить на dbd Хотя... полноценных регулярок нехватат... Иногда встречаются такие задачи... P.S.: а парсить нуно... до того как данные ложатся в базу Согласен. Надо парсить до базы, но есть ограничение по времени ... Пока есть то, что есть ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2013, 12:10 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
Testor1sphinx_mvпропущено... За такие "цели" постановщику задачи "светит" пожизненная дисквалификация в дворники! Додуматься заставить писать для SQL-сервера "плюшки", которые вместо серверного движка будут на этом же самом сервере выполнять недо-запросы на LINQ (хоть и Parallel) - бред редкостный... Учите SQL и T-SQL - и будет Вам счастье! Вместе с самым быстрым и даже очень параллельным (в зависимости от версии, редакции и настроек SQL-сервера) выполнением запросов к данным. Аминь! Речь не идет о стандартных запросах.Для серверов БД практически не существует "нестандартных запросов" - по крайней мере, мне такие не встречались. Все, что "нестандартное" (обычно касается очень сложных отчетов) реализуется несколько "более другими" средствами. При этом элементарные (для SQL) типы запросов становятся весьма нетривиальными при попытке их реализации на LINQ. Testor1Иногда требуется обрабатывать данные (парсить) на уровне базы.На уровне БД? "Ремонтируйте" структуру данных, хранящихся в БД: при возникновении таких "задач" налицо нарушение основных правил проектирования реляционных БД. В частности, не соблюдается первая нормальная форма , и конкретно - ее условие, когда каждый столбец каждой записи должен содержать только одно значение из соотвествующего домена . ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2013, 12:22 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
sphinx_mvTestor1пропущено... Речь не идет о стандартных запросах.Для серверов БД практически не существует "нестандартных запросов" - по крайней мере, мне такие не встречались. Все, что "нестандартное" (обычно касается очень сложных отчетов) реализуется несколько "более другими" средствами. При этом элементарные (для SQL) типы запросов становятся весьма нетривиальными при попытке их реализации на LINQ. Testor1Иногда требуется обрабатывать данные (парсить) на уровне базы.На уровне БД? "Ремонтируйте" структуру данных, хранящихся в БД: при возникновении таких "задач" налицо нарушение основных правил проектирования реляционных БД. В частности, не соблюдается первая нормальная форма , и конкретно - ее условие, когда каждый столбец каждой записи должен содержать только одно значение из соотвествующего домена . Импортируются булк инсертом огромные csv файлы. Несколько 10-20 ГБ данных в файле. Некоторые из полей перед вставкой в базу нужно распарсить и удалить ненужные данные. В базу грузятся не все поля. Если писать отдельную программку для обработки файлов, то для обработки файлов тоже нужно время ... Короче спорный вопрос, что быстрее ... времени проводить экспериментов на данный момент нет, но в будущем такие тесты будут проведены. Вторая задача грузить не все строки, а только те которые прописаны в табличном справочнике (products_list) в базе данных. Третья задача подсчитать, сколько реально было строк файле и сколько из них импортировалось. Все уже реализовано на уровне OPENROWSET BULK INSERT + CLR. Есть возможность вторую задачу ускорить за счет plinq. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2013, 12:35 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
Testor1Импортируются булк инсертом огромные csv файлы. Несколько 10-20 ГБ данных в файле. Некоторые из полей перед вставкой в базу нужно распарсить и удалить ненужные данные. В базу грузятся не все поля. Если писать отдельную программку для обработки файлов, то для обработки файлов тоже нужно время ... Короче спорный вопрос, что быстрее ... времени проводить экспериментов на данный момент нет, но в будущем такие тесты будут проведены. "Лисапет" - оно, конечно, хорошо... Только перед тем как "проводить тесты", ознакомьтесь (сугубо во избежание) с более стандартными и универсальными средствами, например, SQL Server Integration Services И (опять же во избежание) попробуйте все же сначала провести эксперименты и тесты, перед тем как совершенно непродуктивно тратить время на "окончательную разработку". Кстати... Из каких соображений Вы предположили, что "парсинг данных в БД" займет меньше времени и ресурсов, чем парсинг и загрузка данных из внешнего приложения? Учтите, что объем вычислений и данных для обоих случаев одинаковый... Testor1Вторая задача грузить не все строки, а только те которые прописаны в табличном справочнике (products_list) в базе данных. И Вас ни разу не терзают смутные сомнения в правильности выбраной стратегии (грузить все это на сервер для обработки и фильтрации нужных данных)? :) Testor1Третья задача подсчитать, сколько реально было строк файле и сколько из них импортировалось.Да... Интересная "диагностическая" информация... Но, по большому счету, совершенно бесполезная... Testor1Все уже реализовано на уровне OPENROWSET BULK INSERT + CLR. Есть возможность вторую задачу ускорить за счет plinq.Стесняюсь спросить... А SQL сервер уже не умеет BULK INSERT без OPENROWSET ??? Использование "не тех" инструментов "не в тех" местах... В общем, "не взлетит" (с) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2013, 13:48 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
sphinx_mvTestor1Импортируются булк инсертом огромные csv файлы. Несколько 10-20 ГБ данных в файле. Некоторые из полей перед вставкой в базу нужно распарсить и удалить ненужные данные. В базу грузятся не все поля. Если писать отдельную программку для обработки файлов, то для обработки файлов тоже нужно время ... Короче спорный вопрос, что быстрее ... времени проводить экспериментов на данный момент нет, но в будущем такие тесты будут проведены. "Лисапет" - оно, конечно, хорошо... Только перед тем как "проводить тесты", ознакомьтесь (сугубо во избежание) с более стандартными и универсальными средствами, например, SQL Server Integration Services И (опять же во избежание) попробуйте все же сначала провести эксперименты и тесты, перед тем как совершенно непродуктивно тратить время на "окончательную разработку". Кстати... Из каких соображений Вы предположили, что "парсинг данных в БД" займет меньше времени и ресурсов, чем парсинг и загрузка данных из внешнего приложения? Учтите, что объем вычислений и данных для обоих случаев одинаковый... Testor1Вторая задача грузить не все строки, а только те которые прописаны в табличном справочнике (products_list) в базе данных. И Вас ни разу не терзают смутные сомнения в правильности выбраной стратегии (грузить все это на сервер для обработки и фильтрации нужных данных)? :) Testor1Третья задача подсчитать, сколько реально было строк файле и сколько из них импортировалось.Да... Интересная "диагностическая" информация... Но, по большому счету, совершенно бесполезная... Testor1Все уже реализовано на уровне OPENROWSET BULK INSERT + CLR. Есть возможность вторую задачу ускорить за счет plinq.Стесняюсь спросить... А SQL сервер уже не умеет BULK INSERT без OPENROWSET ??? Использование "не тех" инструментов "не в тех" местах... В общем, "не взлетит" (с) 1) Пытался написать свой лоадер на c#. openrowset - работал быстрее и был более универсальным. Использовал openrowset, а не bcp и bulk insert - по нескольким причинам. Возможность использовать формат файл и отсекать ненужные столбцы. Фильтрация по условию. С помощью "хитрого", но не совсем правильного запроса была возможность подсчитать кол-во строк в файле и тех, которые были проинсерчены. И самое главное - было удобно настраивать и контролировать все процессы и tsql. Когда нужно обработать и загрузить несколько файлов и загрузить их в определенном порядке, то проще это делать в одном месте. Это с учетом текущего опыта. В базу попадало только 10 столбцов из 500. Только один столбец нужно было дополнительно парсить. Технически это было проще сделать на CLR. 2) Стандартные библиотеки c# медленные. Для небольших задач они подходят. На тяжелых задачах нужно использовать С. Времени не было на переключаться на С. Работа со строками там работает побыстрее. 3) Файлы содержат кол-во строк в файле. Нужно сверяться, что кол-во строк файле совпадает с именем файлы. Данные очень ценные и недопустимы были ошибки. Пришлось пойти на жертвы по скорости. На практике бывали случаи с неполными данными в файле. 4) SQL конечно умеет, но использовал то, что более подходило. Встречный вопрос - SSIS на сколько медленее, чем bcp и позволяет ли он подсчитать кол-во строк файле и строк сколько было проинсерченно? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2013, 14:17 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
Testor1, Есть понимание - как надо правильно все делать, но нужно свободное время и набраться опыта по определенным технологиям. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2013, 14:21 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
Testor1пропущено... 1) Пытался написать свой лоадер на c#. openrowset - работал быстрее и был более универсальным. Использовал openrowset, а не bcp и bulk insert - по нескольким причинам. Возможность использовать формат файл и отсекать ненужные столбцы. Фильтрация по условию. С помощью "хитрого", но не совсем правильного запроса была возможность подсчитать кол-во строк в файле и тех, которые были проинсерчены. И самое главное - было удобно настраивать и контролировать все процессы и tsql. Когда нужно обработать и загрузить несколько файлов и загрузить их в определенном порядке, то проще это делать в одном месте. Это с учетом текущего опыта. Это все было еще в DTS от SQL2000... Testor1В базу попадало только 10 столбцов из 500. Только один столбец нужно было дополнительно парсить. Технически это было проще сделать на CLR. Надеюсь, Вы отдаете себе отчет, что "проще" != "лучше"? С другой стороны, "работает - не трогай"... :) Testor12) Стандартные библиотеки c# медленные. Для небольших задач они подходят. На тяжелых задачах нужно использовать С. Времени не было на переключаться на С. Работа со строками там работает побыстрее. Немножко, как бы, заблуждение... Есть "система", которая каждые 5 минут "выплевывает" пару-тройку гигабайт текста в CSV-формате... Текст нужно распарсить, отфильтровать и агрегировать по определенным, достаточно нетривиальным условиям... "Самописный" (на c#) загрузчик грузит это "счастье" примерно 30-40 секунд - полный цикл: чтение исходного файла... парсинг, фильтрация, агрегация - "на лету"... загрузка в БД... И все - "стандартное"... Testor1Встречный вопрос - SSIS на сколько медленее, чем bcp и позволяет ли он подсчитать кол-во строк файле и строк сколько было проинсерченно?Зависит от того, что и как будете использовать и настраивать для загрузки данных... Подключите нему bcp - будет так же... Подключите BULK INSERT - совсем другой "суп"... Плюс вопросы оптимизации массовой загрузки для БД никто не отменял... ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2013, 16:12 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
sphinx_mvНемножко, как бы, заблуждение... Есть "система", которая каждые 5 минут "выплевывает" пару-тройку гигабайт текста в CSV-формате... Текст нужно распарсить, отфильтровать и агрегировать по определенным, достаточно нетривиальным условиям... "Самописный" (на c#) загрузчик грузит это "счастье" примерно 30-40 секунд - полный цикл: чтение исходного файла... парсинг, фильтрация, агрегация - "на лету"... загрузка в БД... И все - "стандартное"... Звучит просто и красиво :) А вы попробуйте. Я на практике пробывал. Может быть у вас опыта побольше. Чего только стоит String.Split по производительности :) А всего одна строчка :) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2013, 16:39 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
Testor1, Предлагаю всем спецам, предложить способ оптимизировать данный скрипт. Он по времени разархивирует и обрабатывает данные медленнее, чем связка ungzip разархивации и импорта полученного файла через openrowset bulk insert в базу. Скрипт был написан на скорую руку для теста и не претендует на роль "правильно" написанного. Прошу дать реальные ценные рекомендации по оптимизации на реальном примере. Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97.
... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2013, 10:08 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
Testor1, приложите архив с образцами ввода и вывода. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2013, 13:46 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
Lelouch, Пример две строчки из файлов выгрузок. В реальности таких строк до 20 миллионов в одном файле, а таких несколько в день. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2013, 14:04 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
Testor1, я не спец, но попробуйте так. Без String.Split во всяком случае ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2013, 15:12 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
Возможно еще выгоднее сделать 1 Replace по тексту результата, а не на каждую строчку ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2013, 15:22 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
LelouchВозможно еще выгоднее сделать 1 Replace по тексту результата, а не на каждую строчку результат тестов сообщу в понедельник. Вопрос, почему выгоднее ? Как я понимаю, системе нужно будет на каждый REPLACE выделять память для новой строки. А если строка большая, то будут тратиться значительные ресурсы на поиск и выделение памяти. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2013, 16:51 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
Testor1, Внутри replace вполне может использоваться StringBuilder, а не String ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2013, 16:58 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
LelouchTestor1, Внутри replace вполне может использоваться StringBuilder, а не String Даже если это так, то все равно нужно выделять память для новой обработанной строки и копировать части строк из старой в новую. Или я не прав ? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2013, 17:37 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2013, 17:45 |
|
CLR & Framework 4.0 & MSSQL 2008 R2
|
|||
---|---|---|---|
#18+
Кстати а зачем вообще регулярка? Убрать все кроме первой группы? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2013, 18:04 |
|
|
start [/forum/topic.php?fid=17&msg=38186134&tid=1350078]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
67ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
others: | 285ms |
total: | 444ms |
0 / 0 |