|
memsql кто-нибудь юзает ?
|
|||
---|---|---|---|
#18+
Решил тут её чутка потестить, благо оно теперь есть в Community Edition и без лимитов 1 агрегатор + 4 лиф-ноды, развернуто на виртуалке с 60Gb RAM Загружаю 100M строк из csv-файла (10GB размер) в таблицу LINEORDER из star schema benchmark На момент старта LOAD'а свободно было 51GB. После загрузки осталось ...2GB ops webUI показывает, что Leaf Table Memory = 37GB (фига себе) и на диск сложила столько же Ну и собственно стандартный вопрос : что делаю не так ? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.02.2016, 10:44 |
|
memsql кто-нибудь юзает ?
|
|||
---|---|---|---|
#18+
Оказалось, что в этом memsql окромя in-memory row-store есть еще disk column-store Пересоздал таблицу LINEORDER, залил csv-шку (уже на 300M строк) Вот такой фуллскан : Код: sql 1.
первым проходом с диска выполняется за 27-28 сек., вторым проходом (видимо уже из кэша файловой системы) выполняется за ...3-4 сек ;-) При этом на первом in-memory варианте (это когда 100M строк LINEORDER в памяти заняли 37GB) этот же запрос выполнялся за 6-7 сек. В обоих случаях 100% утилизация CPU (16 VCPU в виртуалке) Получается, что на одинаковом объеме кэшированный column-store будет в 4-5 раз быстрее in-memory row-store вараинта. Забавно... ... |
|||
:
Нравится:
Не нравится:
|
|||
29.02.2016, 16:21 |
|
memsql кто-нибудь юзает ?
|
|||
---|---|---|---|
#18+
memsql_test, Сколько колонок в исходном csv файле? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2016, 23:57 |
|
memsql кто-нибудь юзает ?
|
|||
---|---|---|---|
#18+
haXbatmemsql_test, Сколько колонок в исходном csv файле? 17 ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2016, 11:31 |
|
memsql кто-нибудь юзает ?
|
|||
---|---|---|---|
#18+
memsql_test, Мне интересно, что получится, если количество колонок уменьшить до 5. По идее row-store должен зарулить. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2016, 18:45 |
|
memsql кто-нибудь юзает ?
|
|||
---|---|---|---|
#18+
Ну в общем похоже (по собщениям на SO), что разбухание исходного датасета в памяти в 3-4 раза это не бага, а фича этого memsql %-) и это такая "оптимизация" под in-memory OLTP. При этом Enterprise-редакция лицензируется по ...гигабайтам RAM ;-) Под что-то более OLAP-ообразное нам такой "инмемори" не нужен. На disk column-store все было красиво (на линейных фулсканах) пока не пошли запросы с джойнами. Ставим "галочку" и едем дальше :) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2016, 15:08 |
|
memsql кто-нибудь юзает ?
|
|||
---|---|---|---|
#18+
memsql_testРешил тут её чутка потестить, благо оно теперь есть в Community Edition и без лимитов а что у Community с лицензией? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2016, 09:09 |
|
memsql кто-нибудь юзает ?
|
|||
---|---|---|---|
#18+
memsql_testОказалось, что в этом memsql окромя in-memory row-store есть еще disk column-store Пересоздал таблицу LINEORDER, залил csv-шку (уже на 300M строк) Вот такой фуллскан : Код: sql 1.
первым проходом с диска выполняется за 27-28 сек., вторым проходом (видимо уже из кэша файловой системы) выполняется за ...3-4 сек ;-) При этом на первом in-memory варианте (это когда 100M строк LINEORDER в памяти заняли 37GB) этот же запрос выполнялся за 6-7 сек. В обоих случаях 100% утилизация CPU (16 VCPU в виртуалке) Получается, что на одинаковом объеме кэшированный column-store будет в 4-5 раз быстрее in-memory row-store вараинта. Забавно... Подымите мне веки. 300М записей, каждая запись по 100 байт (10 гиг = 100 М записей). 28 сек на прочитать все записи с диска. Делим на 4 ноды. Получается по 75 миллинов записей за 28 сек на ноде. Или нода читает 7.5 гиг за 28 сек или 267 мегабайт в секунду, на виртуалке Карл ! И это только чтение, нужно же еще обсчитать это всё. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2016, 01:10 |
|
memsql кто-нибудь юзает ?
|
|||
---|---|---|---|
#18+
Ролг Хупина что у Community с лицензией? как-то так ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2016, 11:15 |
|
memsql кто-нибудь юзает ?
|
|||
---|---|---|---|
#18+
Чойто цифры не сходятся Подымите мне веки. 300М записей, каждая запись по 100 байт (10 гиг = 100 М записей). 28 сек на прочитать все записи с диска. Делим на 4 ноды. Получается по 75 миллинов записей за 28 сек на ноде. Или нода читает 7.5 гиг за 28 сек или 267 мегабайт в секунду, на виртуалке Карл ! И это только чтение, нужно же еще обсчитать это всё. Дык колоночное хранение, для данного запроса читаются только страницы содержащие 2 колонки, а не все 17 Выставляем фс-кэш : Код: sql 1.
Пускаем запрос : Код: sql 1.
: Cмотрим iostat : Код: sql 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. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110.
Получаем результат : Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
А что 267 mbps это какие-то недостижимые цифры для VMWare ESX ? Видел и в разы больше. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2016, 11:47 |
|
|
start [/forum/search_topic.php?author=eoschool&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
73ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
others: | 895ms |
total: | 1089ms |
0 / 0 |