Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
авторА что это за база "Пастухова"? Оффлайн база кеев для сеошников. Полезна для некоторых тематик. авторКто этот замечательный человек? Программист. ИНН 920156526734, он ИП https://egrul.nalog.ru/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 20:05 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
авторНапротив, из его слов можно предположить, что у него есть некие тексты на языках народов мира. Тогда я сдаюсь. Чо то шибко много тб для всех слов в мире. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 20:06 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
mikronAleksandr Sharahovпропущено... Всю остальную хрень не читаем из файла, для отбора дубликатов она не требуется. Интересный поворот мысли. Другими словами в моём примере вы удалите все строчки за исключением первой как дубликаты? Вас ничего не смущяет? Нет, не смущает. Была задача удалить дубликаты - я удаляю. Будет задача объединить - объединю. Что не так? :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 20:07 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
maytonИ никакой сортировки. Как вам? Зачтено. Вопрос в том, умеют ли DBMS такие и подобные методы? Я думаю что нет, и это мой аргумент против DBMS для этой задачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 20:10 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
maytonИ никакой сортировки. Как вам? Может и заработает, только 38 неправильная цифра, больше надо, учитывай служебную инфу и размер страницы 4 кб, т.к. при нехватке памяти все что касается чанка должно постоянно быть памяти, т.е. не должно быть свопа пока в хэш-таблицу грузится один чанк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 20:13 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
Aleksandr SharahovБыла задача удалить дубликаты - я удаляю. Что не так? :-) Вобще-то вопрос был риторический но если вам не непонятно: вы удалили оригинальные данные а не дубликаты allow;ru;разрешать и не одно и то же что allow;ru;позволять и уж совсем не дубликат allow;de;erlauben ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 20:23 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
mikronAleksandr SharahovБыла задача удалить дубликаты - я удаляю. Что не так? :-) Вобще-то вопрос был риторический но если вам не непонятно: вы удалили оригинальные данные а не дубликаты allow;ru;разрешать и не одно и то же что allow;ru;позволять и уж совсем не дубликат allow;de;erlauben Вобще-то, и ответ был риторический, но если вам не непонятно, то без четкого определения дубликата спорить абсолютно бессмысленно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 20:25 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
mikronmaytonИ никакой сортировки. Как вам? Зачтено. Вопрос в том, умеют ли DBMS такие и подобные методы? Я думаю что нет, и это мой аргумент против DBMS для этой задачи. DBMS умеет по другому. Он бъет сложным и универсальным ударом который называется B+Tree. Это дерево. Но особое. Оптимизированное для дисковых блочных операций. И разумеется оно нелетает без прослойки LRU-подобного кеша блоков. По сути табличка с индексом решает эту задачу универсально и квази-линейно масштабируется до 150 Гиг и до петабайт. Зависит от нашей жадности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 20:43 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
Aleksandr Sharahovmikronпропущено... Вобще-то вопрос был риторический но если вам не непонятно: вы удалили оригинальные данные а не дубликаты allow;ru;разрешать и не одно и то же что allow;ru;позволять и уж совсем не дубликат allow;de;erlauben Вобще-то, и ответ был риторический, но если вам не непонятно, то без четкого определения дубликата спорить абсолютно бессмысленно. Ну и чудесно, теперь надеюсь вам понятно, что ваше утверждение что хеш-таблица прекрасно справится беспочвенно. Как некоторые уже писал, зависит от количества уникальных ключей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 20:45 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
mikronAleksandr Sharahovпропущено... Вобще-то, и ответ был риторический, но если вам не непонятно, то без четкого определения дубликата спорить абсолютно бессмысленно. Ну и чудесно, теперь надеюсь вам понятно, что ваше утверждение что хеш-таблица прекрасно справится беспочвенно. Как некоторые уже писал, зависит от количества уникальных ключей. Я и не утверждал, что хеш-таблица справится со всеми задачами, которые вы придумаете. Я лишь считаю, что с задачей автора, как я ее понимаю, хеш-таблица справится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 20:51 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
Dima TmaytonИ никакой сортировки. Как вам? Может и заработает, только 38 неправильная цифра, больше надо, учитывай служебную инфу и размер страницы 4 кб, т.к. при нехватке памяти все что касается чанка должно постоянно быть памяти, т.е. не должно быть свопа пока в хэш-таблицу грузится один чанк. Заработает! Не сомневайся! Ученье Маркса правильно, потому что оно - верно! Принципиально-то алгоритм рабочий? А по сабжу... то что ты говоришь - это тонкая настройка структур данных. Я там по тексту упомянул что на 4Г ключей (по суммарной длине) я резервирую аж 2Г служебной инфы. По моему это более чем достаточно для всех "гранулярных" структур данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 20:54 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
mayton4Г ключей (по суммарной длине) Ну откуда вы эти предположения берете? ТС ничего не сказал по этому поводу. Исходи из худшего: все значения уникальны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 20:59 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
Андрей Александрович., в словарях практически нет повторений статей по слову(помогала как-то форматировать в ворде 2 словаря) все строки разные(длина статьи доходила до 9кб, причем заносилось сие в одну ячейку) привожу пример --это может быть в одной записи case сущcase [keɪs] сущ fact • matter • argument • reality • thing • affair • deedслучайм, делоср, примермinstance • example • precedent • case in point(instance, affair, example)event • occasion • occurrenceкорпусм, кожухмbox • housing • enclosure • body • cabinet • chassis • corps • pencil case(housing)causeчехолм, футлярм, ящикм, чемоданм, коробкаж, кейсм, сумкаж, крышкажlawsuit • court case • legal case(cover, box, bag, briefcase)обстоятельствоср, фактм(circumstance, fact)больной, пациентм(patient)историяж, история болезни(history)заболеваниеср(disease)регистрм(register)вариантм(option)шкафм(cabinet)прецедентм(precedent)витринаж(window)падежм(mortality)доводымположениеср(situation)контейнерм(container)кассетаж(magazine) так что для начала надо видимо создать индексные файлы(150гб будет много меньше ) при этом получим статистику --а сколько слов в словаре, средняя длина стать --имя словаря --язык --порядковый номер в справочнике --ключевое слово статьи ведь может потребоваться пересобирать источники в другом порядке, можно сначала собрать мелочь, получив единый(ничего не удаляя),а только потом сливать с базовым ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 21:02 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
maytonПринципиально-то алгоритм рабочий? Рабочий. При большом количестве ключей надо будет допилить распределение по чанкам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 21:05 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
maytonВам дан текстовый файл. 150Gb. В формате csv. их хотя и не без проблем можно разбить на 15 по 1 гб, хотя если статьи длинные --- частей может быть и меньше 150гб --это не показатель сколько это записей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 21:05 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
Aleksandr Sharahovmikronпропущено... Ну и чудесно, теперь надеюсь вам понятно, что ваше утверждение что хеш-таблица прекрасно справится беспочвенно. Как некоторые уже писал, зависит от количества уникальных ключей. Я и не утверждал, что хеш-таблица справится со всеми задачами, которые вы придумаете. Я лишь считаю, что с задачей автора, как я ее понимаю, хеш-таблица справится. Нет сомнений что справится. Есть просто разные оценки времени. Алгоритм который я предложил делает минимум 2 full scan по 150 Гб пространству ключей (построение 38 чанков и работа с каждым из них отдельно). Сортировка о которой говорили выше в такой постановке не то чтобы не возможна. Она возможна. Но вангую что под капотом у утилит sort, unique, e.t.c лежит знаметитая "дисковая сортировка слиянием" (она -же ленточная, она-же merge) которая перелопатит наши 150 Гиг не один и не два а логарифм ... хер там от какого числа итераций, количество которых будет определяться эффетивностью первой фазы. Поэтому когда мне говорят о сортировке 150 Гиг - я улыбаюсь. Попробуйте... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 21:07 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
Dima Tmayton4Г ключей (по суммарной длине) Ну откуда вы эти предположения берете? ТС ничего не сказал по этому поводу. Исходи из худшего: все значения уникальны. Дима так все чики-пики. Я беру worst-scenario! Я беспокоюсь о том чтобы вы не получили out of memory error. Все 4 Гига уникальны? Отлично. Они все лягут нормик в хеш-табличку. Будет 50% дублей? Отлично. Они свернуться на 2-й фазе когда мы отработаем всех 38 попугаев. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 21:10 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
ПЕНСИОНЕРКАmaytonВам дан текстовый файл. 150Gb. В формате csv. их хотя и не без проблем можно разбить на 15 по 1 гб, хотя если статьи длинные --- частей может быть и меньше 150гб --это не показатель сколько это записей +1 Ваш поинт про сколько записей очень верный! И я его коснусь в моем втором алгоритме. Который я опишу чуть позже если топик еще будет актуален. Выше вы пишете про 15 по 1Гб? Вы хотели сказать 15 по 10Гб? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 21:13 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
maytonmikronпропущено... Зачтено. Вопрос в том, умеют ли DBMS такие и подобные методы? Я думаю что нет, и это мой аргумент против DBMS для этой задачи. DBMS умеет по другому. Он бъет сложным и универсальным ударом который называется B+Tree. Это детали реализации но суть останется - сортировка всех данных. это точно не лучше того что вы предложили. Интересно что могут предложить монстры оптимизации от DBMS. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 21:18 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
maytonВсе 4 Гига уникальны? Отлично. Они все лягут нормик в хеш-табличку. Будет 50% дублей? Отлично. Они свернуться на 2-й фазе когда мы отработаем всех 38 попугаев. Изначально озвучено 2 Тб, считай что они все уникальны, ну или упрости до 50%, т.е. 1 Тб уникальных. Какие 4 Гб? хэш-таблица на 2 Тб имеет право на жизнь, только надо ОС оповестить чтобы она не убила прогу запросившую столько памяти и память с умом использовать, т.е. чтобы не постоянный своп, а нужное в большинстве случаев оказывалось уже отраженным в физическую память. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 21:25 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
mikronmaytonпропущено... DBMS умеет по другому. Он бъет сложным и универсальным ударом который называется B+Tree. Это детали реализации но суть останется - сортировка всех данных. это точно не лучше того что вы предложили. Интересно что могут предложить монстры оптимизации от DBMS. Они не сортируют. Они - строют дерево. Согласись - постановка звучит как-то по другому. А если ты сделаешь Код: sql 1. и при этом word будет не проиндексирован - то оптимизатор DBMS (Oracle - к примеру) автоматически сольет всю выборку в табличное пространство TEMP. Потом отсортирует теми-же алгоритмами что и мы обсуждали и потом выдаст курсор из этого TEMP пространства временных упорядоченных данных. Ничто не ново! Поэтому безсмысленно спрашивать что дескыть DBMS-вендор предложит. Мы - разрабатываем задачу. И мы отвечаем за эффективность ее решения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 21:28 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
Dima TmaytonВсе 4 Гига уникальны? Отлично. Они все лягут нормик в хеш-табличку. Будет 50% дублей? Отлично. Они свернуться на 2-й фазе когда мы отработаем всех 38 попугаев. Изначально озвучено 2 Тб, считай что они все уникальны, ну или упрости до 50%, т.е. 1 Тб уникальных. Какие 4 Гб? хэш-таблица на 2 Тб имеет право на жизнь, только надо ОС оповестить чтобы она не убила прогу запросившую столько памяти и память с умом использовать, т.е. чтобы не постоянный своп, а нужное в большинстве случаев оказывалось уже отраженным в физическую память. Ну... здесь без автора трудно что-то спорить и доказывать. Но насколько я понял его первый пост. 2 Тб - это все справочники всех языков. А 150Гб - это просто один из самых толстых справочников. Нужно-ли гарантировать кросс-уникальность между справочниками? Я не знаю. Скорее всего нет. Это должно быть гарантировано кодовой страницей. Финские слова не пересекаются со шведскими. Если я ошибаюсь - то пускай ТС - откомментарит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 21:31 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
Автор говорил о "списках слов на разных языках" и все. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 21:39 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
Делим на чанки 2Терабайта... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 21:40 |
|
||
|
Работа с большими данными
|
|||
|---|---|---|---|
|
#18+
maytonDBMS умеет по другому. Он бъет сложным и универсальным ударом который называется B+Tree. Это дерево. Но особое. Оптимизированное для дисковых блочных операций. И разумеется оно нелетает без прослойки LRU-подобного кеша блоков. Первый раз такую трактовку слышу, про оптимизацию с дисками. Не поделитесь источником ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2017, 21:41 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=39508167&tid=1340295]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
191ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
| others: | 14ms |
| total: | 313ms |

| 0 / 0 |
