Сітка даних JavaScript на мільйони рядків [закрито]

Мені потрібно представити великій кількості рядків даних (тобто мільйони рядків) користувачеві в сітці за допомогою JavaScript.

Користувач не повинен бачити сторінки або переглядати лише обмежені кількості даних одночасно.

Швидше, мабуть, здається, що всі дані доступні.

Замість того, щоб завантажувати дані відразу, завантажуються невеликі шматки, коли користувач приходить до них (тобто, прокручуючи сітку).

Рядки не редагуватимуться через цей передній кінець, тому сітки лише для читання є прийнятними.

Які сітки даних, написані на JavaScript, існують для такого типу безперебійних підказок?

( Відмова: Я автор SlickGrid )

ОНОВЛЕННЯ Це зараз реалізовано в SlickGrid .

Будь ласка, перегляньте http://github.com/mleibman/SlickGrid/isissue#issue/22 для постійної дискусії про те, як зробити SlickGrid працювати з більшою кількістю рядків.

Проблема полягає в тому, що SlickGrid не віртуалізує саму смугу прокрутки - висота області прокрутки встановлюється на загальну висоту всіх рядків. Рядки все ще додаються та видаляються під час прокрутки користувача, але сама прокрутка здійснюється браузером. Це дозволяє йому бути дуже швидким, але плавним (події в режимі прокрутки, як правило, повільно). Застереження полягає в тому, що в CSS-системах браузера є помилки / обмеження, які обмежують потенційну висоту елемента. Для IE це може бути 0x123456 або 1193046 пікселів. Для інших браузерів вона вище.

У гілці "largenum-fix" існує експериментальне вирішення, яке значно збільшує цю межу, заселяючи область, що прокручується, "сторінками", встановленими на висоту 1М пікселів, а потім використовуючи відносне позиціонування на цих сторінках. Оскільки обмеження висоти у двигуні CSS здається іншим та значно нижчим, ніж у реальному макеті двигуна, це дає нам набагато більшу верхню межу.

Я все ще шукаю спосіб досягти необмеженої кількості рядків, не відмовляючись від меж продуктивності, який SlickGrid наразі має для інших реалізацій.

Рудігере, ти можеш детальніше розповісти, як ти це вирішив?

https://github.com/mleibman/SlickGrid/wiki

" SlickGrid використовує віртуальну візуалізацію, щоб ви могли легко працювати з сотнями тисяч елементів без будь-якого падіння продуктивності. Насправді, різниці в продуктивності між роботою з сіткою з 10 рядів проти 100 000 рядків. "

Деякі основні моменти:

• Адаптивне віртуальне прокручування (обробляйте сотні тисяч рядків)
• Надзвичайно велика швидкість візуалізації
• Фон після візуалізації для більш багатих комірок
• Налаштовується та настроюється
• Повна навігація по клавіатурі
• Змінити розмір стовпця / змінити порядок / показати / приховати
• Автоматизація стовпців та пристосування
• Підключені формати і редактори комірок
• Підтримка редагування та створення нових рядків. "від mleibman

Це безкоштовно (ліцензія MIT). Він використовує jQuery.

Найкращі сітки, на мою думку, наведені нижче:

• Flexigrid: http://flexigrid.info/
• Сітка jQuery: http://www.trirand.com/blog/
• jqGridView: http://plugins.jquery.com/project/jqGridView
• jqxGrid: http://www.jqwidgets.com/
• Інгрід: http://reconstrukt.com/ingrid/
• SlickGrid http://github.com/mleibman/SlickGrid
• DataTables http://www.datatables.net/index
• ShieldUI http://demos.shieldui.com/web/grid-virtualization/performance-1mil-rows

Мої найкращі 3 варіанти - jqGrid, jqxGrid та DataTables. Вони можуть працювати з тисячами рядків і підтримувати віртуалізацію.

Я не маю на увазі розпочати полум’яну війну, але припускаючи, що ваші дослідники люди, ви їх не знаєте так добре, як ви думаєте. Тільки тому, що у них є петабайти даних, це не робить їх здатним переглядати навіть мільйони записів у будь-який змістовний спосіб. Вони можуть сказати, що хочуть побачити мільйони записів, але це просто нерозумно. Попросіть ваших розумніших дослідників зробити якусь основну математику: припустимо, що вони витрачають 1 секунду на перегляд кожного запису. З такою швидкістю знадобиться 1000000 секунд, що працює більше шести тижнів (40 годин робочих тижнів без перерв на їжу чи туалет).

Вони (або ви) серйозно думаєте, що одна людина (та, яка дивиться на сітку) може зібрати таку концентрацію? Чи справді вони багато чого роблять за цю секунду, або вони (скоріше) фільтрують речі, які не хочуть? Я підозрюю, що після перегляду підмножини "розумного розміру" вони могли б описати вам фільтр, який автоматично відфільтрував би ці записи.

Як випливали також paxdiablo і Sleeper Smith і Lasse V Karlsen, ви (і вони) не продумали вимог. З іншого боку, тепер, коли ви знайшли SlickGrid, я впевнений, що необхідність цих фільтрів стала негайно очевидною.

Я можу сказати з досить хорошою впевненістю, що вам серйозно не потрібно показувати мільйони рядків даних користувачеві.

У світі немає жодного користувача, який зможе зрозуміти або керувати цим набором даних, навіть якщо технічно вдається витягнути його, ви не вирішите жодної відомої проблеми для цього користувача.

Натомість я б зосередився на тому, чому користувач хоче бачити дані. Користувач не хоче бачити дані просто для того, щоб побачити дані, зазвичай виникає запитання. Якщо ви зосередьтесь на тому, щоб відповісти на ці запитання, то ви були б набагато ближче до чогось, що вирішує актуальну проблему.

Я рекомендую сітку Ext JS з функцією "Буферний вигляд".

http://www.extjs.com/deploy/dev/examples/grid/buffer.html

(Відмова: Я є автором w2ui)

Нещодавно я написав статтю про те, як реалізувати сітку JavaScript з 1 мільйоном записів ( http://w2ui.com/web/blog/7/JavaScript-Grid-with-One-Million-Records ). Я виявив, що в кінцевому рахунку є 3 обмеження, які заважають приймати його більш високо:

1. Висота діва має обмеження (можна подолати віртуальною прокруткою)
2. Такі операції, як сортування та пошук, починають повільно після 1 мільйона записів або близько того
3. Оперативна пам’ять обмежена, оскільки дані зберігаються в масиві JavaScript

Я перевірив сітку з 1 мільйоном записів (крім IE), і вона працює добре. Дивіться статтю щодо демонстрацій та прикладів.

dojox.grid.DataGrid пропонує абстрагування даних JS, щоб ви могли підключити їх до різноманітних програм у наданих магазинах dojo.data або написати свій власний. Очевидно, вам знадобиться такий, який підтримує випадковий доступ для цих багатьох записів. DataGrid також забезпечує повну доступність.

Редагуйте, ось ось посилання на статтю Меттью Рассела, яка має навести потрібний вам приклад, переглядаючи мільйони записів за допомогою dojox.grid. Зауважте, що він використовує стару версію сітки, але концепції однакові, були лише деякі несумісні поліпшення API.

О, і це абсолютно безкоштовно з відкритим кодом.

Я використовував jQuery Grid Plugin , це було приємно.

Демо

Ось кілька оптимізацій, які ви можете застосувати, щоб прискорити роботу. Просто думаючи вголос.

Оскільки кількість рядків може бути мільйонами, вам потрібна система кешування лише для даних JSON з сервера. Я не можу собі уявити, щоб хто-небудь захотів завантажити всі X мільйони предметів, але якби це було, це буде проблемою. Цей невеликий тест на Chrome для масиву на 20M + цілих чисел постійно виходить з ладу на моїй машині.

var data = [];
for(var i = 0; i < 20000000; i++) {
    data.push(i);
}
console.log(data.length);​

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

Для самих комірок таблиці я думаю, що побудувати / знищити DOM-вузли може дорого. Натомість ви можете просто заздалегідь визначити кількість X комірок, і щоразу, коли користувач прокручується до нового положення, вводите дані JSON у ці комірки. Панель прокрутки практично не має прямого відношення до того, скільки місця (висоти) потрібно для представлення всього набору даних. Ви можете довільно встановити висоту контейнера таблиці, скажімо, 5000px, і зіставити їх із загальною кількістю рядків. Наприклад, якщо висота контейнерів становить 5000 пікселів і в цілому є 10 М рядків, то starting row ≈ (scroll.top/5000) * 10Mде scroll.topпредставлено відстань прокрутки від верхньої частини контейнера. Тут невелика демонстрація .

Щоб визначити, коли потрібно запитувати більше даних, в ідеалі об'єкт повинен виступати посередником, який слухає події прокрутки. Цей об'єкт відслідковує, наскільки швидко користувач прокручується, і коли схоже на те, що користувач сповільнюється або повністю зупинився, робить запит даних для відповідних рядків. Отримання даних таким чином означає, що ваші дані будуть фрагментовані, тому кеш повинен бути розроблений з урахуванням цього.

Також важлива роль може відігравати обмеження браузера щодо максимальних вихідних з'єднань. Користувач може прокрутити до певної позиції, яка запустить запит AJAX, але перед цим завершення користувач може прокрутити до якоїсь іншої частини. Якщо сервер не реагує достатньо, запити будуть чергуватися, і програма виглядатиме невідповідно. Ви можете використовувати диспетчер запитів, за допомогою якого проводяться всі запити, і він може скасувати очікувані запити, щоб звільнити місце.

Я знаю, що це старе питання, але все-таки .. Є також dhtmlxGrid, який може обробляти мільйони рядків. Існує демонстрація з 50 000 рядків, але кількість рядків, які можна завантажувати / обробляти в сітці, необмежена.

Відмова: Я з команди DHTMLX.

Я пропоную вам прочитати це

http://www.sitepen.com/blog/2008/11/21/effective-use-of-jsonreststore-referencing-lazy-loading-and-more/

Відмова: Я активно використовую YUI DataTable без жодного головного болю протягом тривалого часу . Він потужний і стабільний. Для ваших потреб, ви можете використовувати ScrollingDataTable Wich suports

• x-прокрутка
• y-прокрутка
• xy-прокрутка
• Потужний механізм подій

Для того, що вам потрібно, я думаю, що ви хочете, це tableScrollEvent . Його API говорить

Запускається, коли фіксована прокрутка DataTable має прокрутку.

Оскільки кожен DataTable використовує DataSource, ви можете контролювати його дані через tableScrollEvent разом з розміром циклу візуалізації , щоб заповнити ваш ScrollingDataTable відповідно до ваших потреб.

Розмір циклу візуалізації говорить

У випадках, коли вашій DataTable потрібно відображати весь великий набір даних, конфігурація renderLoopSize може допомогти керувати візуалізацією DOM браузера, щоб потік інтерфейсу не замикався на дуже великих таблицях . Будь-яке значення, що перевищує 0, призведе до того, що візуалізація DOM буде виконуватися в ланцюгах setTimeout (), які надають вказану кількість рядків у кожному циклі. Ідеальне значення повинно визначатися для кожної реалізації, оскільки немає жорстких та швидких правил, а лише загальні вказівки:

• За замовчуванням renderLoopSize дорівнює 0, тому всі рядки відображаються в одному циклі. RenderLoopSize> 0 додає накладні витрати, тому використовуйте продумано.
• Якщо ваш набір даних достатньо великий (кількість рядків X кількість складності форматування стовпців X), що користувачі відчувають затримку у візуальному візуалізації та / або це спричиняє зависання сценарію, подумайте про встановлення renderLoopSize .
• RenderLoopSize до 50 років, мабуть, не варто. Мабуть, кращий рендерLoopSize> 100.
• Набір даних, мабуть, не вважається достатньо великим, якщо він не має сотень і сотень рядків.
• Наявність renderLoopSize> 0 і <загальних рядків призводить до того, що таблиця буде відображена в одному циклі (такий же, як renderLoopSize = 0), але вона також запускає функціональність, таку як розміщення рядка після візуалізації, оброблятися з окремого потоку setTimeout.

Наприклад

// Render 100 rows per loop
 var dt = new YAHOO.widget.DataTable(<WHICH_DIV_WILL_STORE_YOUR_DATATABLE>, <HOW YOUR_TABLE_IS STRUCTURED>, <WHERE_DOES_THE_DATA_COME_FROM>, {
     renderLoopSize:100
 });

<WHERE_DOES_THE_DATA_COME_FROM> - це лише один джерело даних . Це може бути JSON, JSFunction, XML і навіть один HTML-елемент

Тут ви можете побачити Простий підручник, наданий мною. Зауважте, що жоден інший плагін DATA_TABLE не підтримує одночасне та подвійне клацання одночасно. YUI DataTable дозволяє. І більше, ви можете використовувати його навіть з JQuery без головного болю

Деякі приклади ви можете побачити

• Елемент списку

Не соромтеся запитувати про все, що вам завгодно про YUI DataTable.

з повагою,

Я не бачу сенсу, для jqGrid ви можете використовувати функцію віртуальної прокрутки:

http://www.trirand.net/aspnetmvc/grid/performancevirtualscrolling

але потім знову можна виконати мільйони рядків з фільтруванням:

http://www.trirand.net/aspnetmvc/grid/performancelinq

Я дійсно не бачу сенсу "так, ніби немає сторінок", хоча, я маю на увазі ... немає можливості відобразити одразу в браузері 1 000 000 рядків - це 10 Мб сировини HTML, я не бачу чому користувачі не хочуть бачити сторінки.

Все одно ...

Кращий підхід, про який я міг би придумати, - це завантаження фрагменту даних у форматі json для кожного прокрутки або деякого обмеження до закінчення прокрутки. json можна легко перетворити на об'єкти, а значить, рядки таблиць можна легко побудувати ненав’язливо

Я б дуже рекомендував Open rico . Спочатку це важко реалізувати, але як тільки ти схопиш його, ти ніколи не озиратимешся.

Мені відомо, що цьому питанню вже кілька років, але jqgrid тепер підтримує віртуальну прокрутку:

http://www.trirand.com/blog/phpjqgrid/examples/paging/scrollbar/default.php

але з вимкненою сторінкою

Я пропоную сітку sigma, сігма сітка має вбудовані функції підкачки, які можуть підтримувати мільйони рядків. А також вам може знадобитися віддалене підказка для цього. перегляньте демонстраційну сторінку http://www.sigmawidgets.com/products/sigma_grid2/demos/example_master_details.html

Погляньте на dGrid:

https://dgrid.io/

Я погоджуюся з тим, що користувачам НІКОЛИ НЕ БУДЕ переглядати мільйони рядків даних одночасно, але dGrid може відображати їх швидко (скріншото).

Не кип'ятіть океан, щоб зробити чашку чаю.