powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Работа с большими данными
112 сообщений из 112, показаны все 5 страниц
Работа с большими данными
    #39507923
Приветствую

Подскажите решение следующей задачи

Есть текстовые данные - порядка 2 тб в виде набора файлов ( файлы от 200 мб до 150 гб )
Задача проверить все файлы и удалить дубликаты ( а так же скомпоновать данные )

Правильным ли решением будет использовать для этого СУБД ?
т.e

1 - читаем файл с данными построчно
2 - вносим данные в БД
3 - перед внесением данных проверяем есть ли уже такая запись в БД

Отсюда вопросы

- как лучше проверять уникальность ? SELECT ? LIKE ? хранимой процедурой ? триггером на INSERT ?
- Какую БД лучше всего использовать ? Есть опыт работы с MySQL, MSSQL, SQLite, Firebird
- Есть ли готовые решения для поиска дубликатов в таких обьемах данных ?
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507925
> и удалить дубликаты

Дубликаты данных которые находятся в файлах
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507927
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Александрович., успех этого мероприятия зависит от ваших ресурсов.
Самый прямой и надежный вариант - загрузить используя всякие базёвые
утилиты *loader-s ваши данные в одну табличку. И delete-ом почистить
дубликаты. В запросе использовать аналитические функции (PARTITION BY).
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507940
mikron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Александрович.2 тб в виде набора файлов ( файлы от 200 мб до 150 гб
Это реально много.
Андрей Александрович.Правильным ли решением будет использовать для этого СУБД ?
Скорее нет чем да. И скорее всего все другие вопросы не релевантны.
Андрей Александрович.- Есть ли готовые решения для поиска дубликатов в таких обьемах данных ?
Возможно есть в биоинформатике. Но ваша задача, если я правильно предпологаю, не поиск одного дупликата и не поиск всех дупликатов.

Для создания списков уникальных значений потребуется на скромный взгляд ещё 2 - 3 ТБ.
И считатся это будет наверно дни. на вскидку и без базы данных. Такая работа стоит времени специалиста и за пределами бесплатных консультаций. ИМХО.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507941
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mikron,

хэширование спасет мир
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507947
982183
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1. Речь идет о текстовой неструктурированной информации, или о реляционных данных, хранящихся в текстовом виде?
во втором случае каково количество полей данных?
2. Чем вызван такой способ хранения данных?
2. Чем отличаются отдельные файлы. (Это последовательно обрезанный поток данных, или это данные с разных источников?)
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507950
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>Андрей Александрович., вчера, 23:25 http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1269329&msg=20736437] [20736437]

>...Правильным ли решением будет использовать для этого СУБД ? ...
Рассмотрите такой вариант:
1. Все текстовые файлы находятся в папке файлового сервера - смысловая часть.
2. Поисковая часть (суррогатный_ключ, пользовательское_имя_файла, группа, когда_создан и т.п) находится в записях таблицы(ц) базы данных.
3. Файлы смысловой части имеют имена производные от суррогатного ключа.

С уважением,
Владимир.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507953
9821831. Речь идет о текстовой неструктурированной информации, или о реляционных данных, хранящихся в текстовом виде?
во втором случае каково количество полей данных?


Файлы представляют собой хранилища слов всех языков мира
те списки слов на разных языках

9821832. Чем вызван такой способ хранения данных?


Дали файлы - сказали решить вопрос с дубликатами и хранением

9821832. Чем отличаются отдельные файлы. (Это последовательно обрезанный поток данных, или это данные с разных источников?)

Это файлы с разных источников ( часто даже с различным способом хранения данных - те нужно будет к каждому файлу писать парсер или свою проверку корректности данных. Учитывая что там еще слова на разных языках то переводить все в UNICODE )
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507954
mikronВозможно есть в биоинформатике. Но ваша задача, если я правильно предпологаю, не поиск одного дупликата и не поиск всех дупликатов.


Задача - очистка данных от повторяющихся слов
А так же упорядочивание данных при возможности

mikronДля создания списков уникальных значений потребуется на скромный взгляд ещё 2 - 3 ТБ.
И считатся это будет наверно дни. на вскидку и без базы данных. Такая работа стоит времени специалиста и за пределами бесплатных консультаций. ИМХО.

Есть свободные 3 тб те куда делать временные таблицы есть
По времени если пересчет займет 3-9 дней - не проблема. Вопрос именно в том как наиболее быстро сделать чтобы поиск добавление в БД не заняло например месяц или больше

Я так подозреваю что после решение этой задачи станет обработка данных
А лучше всего это делать если данные будут упорядоченны например в БД
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507958
982183
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Александрович.Файлы представляют собой хранилища слов всех языков мира
те списки слов на разных языках
Т.е. намечается два поля - "Язык" (который берем из файла) и "Cлово"

982183Дали файлы - сказали решить вопрос с дубликатами и хранением
Наверно с хранением и дубликатами.

982183Это файлы с разных источников ( часто даже с различным способом хранения данных - те нужно будет к каждому файлу писать парсер или свою проверку корректности данных. Учитывая что там еще слова на разных языках то переводить все в UNICODE )
Так эта задача однако на порядок сложнее, чем организовать хранение и чистку.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507959
982183
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Почему на этом гр*** форуме нельзя редактировать посты....
Обычную описку исправить нельзя.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507960
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Из коробочных решенийй.

Можно посмотреть на unix-утилиты такие как:
1) sort -u
2) unique

и посмотреть их настройки в части использования $tmp как пространства для сортировок.

Если эти коробочные штуки "не взлетят" то можно попробовать грузить в БД. Но грузить
надо грамотно. Учитывая объем - желательно использовать утилиты для bulk/batch загрузки.
Но дальше об этом говорить безсмысленно. Автор должен сообщить нам какая именно
dbms у него выбрана и дальше уже можно что-то советовать более конкретно.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507961
982183
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А что делать с омонимами?
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507962
maytonИз коробочных решенийй.

Можно посмотреть на unix-утилиты такие как:
1) sort -u
2) unique

и посмотреть их настройки в части использования $tmp как пространства для сортировок.



Спасибо
Изучу

maytonЕсли эти коробочные штуки "не взлетят" то можно попробовать грузить в БД. Но грузить
надо грамотно. Учитывая объем - желательно использовать утилиты для bulk/batch загрузки.
Но дальше об этом говорить безсмысленно. Автор должен сообщить нам какая именно
dbms у него выбрана и дальше уже можно что-то советовать более конкретно.

Вот это был один из вопросов
Есть опыт работы с СУБД

MySQL, MSSQL, SQLite, Firebird
Какую посоветуете для хранения больших данных ? ( к сожалению с Oracle не работал )
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507965
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Александрович.Вот это был один из вопросов
Есть опыт работы с СУБД

MySQL, MSSQL, SQLite, Firebird
Какую посоветуете для хранения больших данных ? ( к сожалению с Oracle не работал )

По этим СУБД я не специалист. Я больше по Oracle.

Немного работал с MSSQL. И конечно исходя
из авторитета самого вендора я порекомендую MSSQL. Кроме того есть
мысль что аналитические (оконные) функции там поддерживаются.

По поводу SQLite - есть сомнения. Она очень производительная но работает
в условиях когда data segment помещается в оперативку. Если вам удастся
ваш самый крупный справочник прогрузить в SQLite - тогда все будет ОК.
Но и с PARTITION BY надо тоже проверить.

По поводу остальных. Велкам в Сравнение. Задавайте вопросы там. Думаю что помогут.
http://www.sql.ru/forum/db-comparison
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507973
schi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
По-моему можно вызять любую СУБД и организовать в ней таблицу с одним полем и уникальным индексом по нему. Далее последовательно читать все файлы и каждое слово пытаться записать в эту таблицу. Если не удалось, то значит дубль, если удалось, то записывать слово в выходной файл.

(Насколько я понял задачу).
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507976
982183
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Т.Е отсечь дублирование на этапе импорта данных....
мысль хорошая.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507977
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А я понял задачу так: например есть у нас три файла разного формата, в каждом из которых подмножество слов французского языка.
Нужно данные каждого файла распарсить, нормализовать и залить в БД.

ИМХО - это простой импорт из различных источников.
Заливаем данные файла в промежуточную таблицу в схеме import, перегоняем в основную только те слова, которых там ещё нет (WHERE NOT EXISTS).
В основной таблице должен быть соответсвующий индекс.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507978
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИМХО большая часть времени уйдёт на написание партеров-загрузчиков из различных форматов.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507979
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Чисто в качестве brainstorm ... можно попробовать зарегаться в Amazon AWS.
И там будут доступны всякие API и хранилища для толстых данных.

Попробовать прогрузить туда табличку в 150Гиг и там отфильтровать.

Возможно но этом шаге Amazon попросит оплатить услугу а может и нет.
Вобщем я-б попробовал. Или взять табличку в два раза меньше и еще раз
попробовать.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507980
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Александрович.,

а вообще как эти данные потом будут использоваться? А то можно и в MongoDB их засунуть с шардированием из коробки.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507981
Aleksandr Sharahov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Все слова одного языка вполне можно обработать в оперативной памяти.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507988
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Aleksandr Sharahov, на чем будешь писать? Delphi? C#?
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507990
skyANAАндрей Александрович.,

а вообще как эти данные потом будут использоваться? А то можно и в MongoDB их засунуть с шардированием из коробки.

По данным планируется поиск и выборка по 200 - 300 тыс записей
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507992
maytonAleksandr Sharahov, на чем будешь писать? Delphi? C#?

Возможно вопрос автору темы

Писать планирую на delphi
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507993
skyANAИМХО - это простой импорт из различных источников.
Заливаем данные файла в промежуточную таблицу в схеме import, перегоняем в основную только те слова, которых там ещё нет (WHERE NOT EXISTS).
В основной таблице должен быть соответсвующий индекс.

Вот тут то и вопрос - как делать правильно ? Для каждого слова делать отдельный запрос в БД ?
Или можно как то триггером это обработать при вставке ?
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507995
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Александрович.maytonAleksandr Sharahov, на чем будешь писать? Delphi? C#?

Возможно вопрос автору темы

Писать планирую на delphi
Да. Все верно. Я как раз автора хотел спросить.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507996
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот тут пишут как при вставке в MS-SQL игнорить ошибки уникальности

https://stackoverflow.com/questions/1139050/how-to-ignore-duplicate-key-error-in-t-sql-sql-server

можно взять за образец. Но поскольку речь идет о большом объеме вставок
я-бы еще почитал как делать тонкую настройку индекса (таблицы?) в MS-SQL
для mass-inserts и еще надо-бы проверить режимы транзакций. Хорошо-бы
это делать одной большой транзакцией чтоб не было накладных расходов
на всякие-там open-close ...e.t.c. Впрочем я тут не спец. Возможно для MS
это не проблема.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507997
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Александрович.По данным планируется поиск и выборка по 200 - 300 тыс записей
Нет никакого смысла связываться с СУБД при таком количестве уникальных данных.
Используйте просто хеш-таблицу в памяти. Это будет самый быстрый вариант.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39507999
Aleksandr Sharahov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Александрович.Возможно вопрос автору темы

Писать планирую на delphi

Ну тогда хеш-таблицы будет достаточно http://guildalfa.ru/alsha/node/32
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508001
Всем спасибо
буду изучать предложенные варианты
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508007
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Александрович.skyANAИМХО - это простой импорт из различных источников.
Заливаем данные файла в промежуточную таблицу в схеме import, перегоняем в основную только те слова, которых там ещё нет (WHERE NOT EXISTS).
В основной таблице должен быть соответсвующий индекс.

Вот тут то и вопрос - как делать правильно ? Для каждого слова делать отдельный запрос в БД ?
Или можно как то триггером это обработать при вставке ?
Не надо никаких отдельных запросов и триггеров.
Вставляете данные из файла в промежуточную таблицу как есть, а из неё уже одним запросом перегоняете в основную с условием WHERE NOT EXISTS.
После этого промежуточную таблицу очищаете.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508009
skyANAАндрей Александрович.пропущено...


Вот тут то и вопрос - как делать правильно ? Для каждого слова делать отдельный запрос в БД ?
Или можно как то триггером это обработать при вставке ?
Не надо никаких отдельных запросов и триггеров.
Вставляете данные из файла в промежуточную таблицу как есть, а из неё уже одним запросом перегоняете в основную с условием WHERE NOT EXISTS.
После этого промежуточную таблицу очищаете.

Спасибо
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508016
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Александрович.буду изучать предложенные варианты
Если файлы текстовые с одним словом на строку, то, вероятнее всего, uniq отработает быстрее, чем вы напишете свой велосипед.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508020
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovАндрей Александрович.буду изучать предложенные варианты
Если файлы текстовые с одним словом на строку, то, вероятнее всего, uniq отработает быстрее, чем вы напишете свой велосипед.
Как быть с его толстым файлом который в 150Г ?
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508025
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovАндрей Александрович.буду изучать предложенные варианты
Если файлы текстовые с одним словом на строку, то, вероятнее всего, uniq отработает быстрее, чем вы напишете свой велосипед.
Я так понял, что это не подходит, потому как повторяющиеся слова разбросаны по разным файлам.
А эти файлы в общем случае могут не одновременно загружаться. При этом ещё и иметь разный формат.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508031
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mikronАндрей Александрович.2 тб в виде набора файлов ( файлы от 200 мб до 150 гб
Это реально много.
Андрей Александрович.Правильным ли решением будет использовать для этого СУБД ?
Скорее нет чем да. И скорее всего все другие вопросы не релевантны.
Андрей Александрович.- Есть ли готовые решения для поиска дубликатов в таких обьемах данных ?
Возможно есть в биоинформатике. Но ваша задача, если я правильно предпологаю, не поиск одного дупликата и не поиск всех дупликатов.

Для создания списков уникальных значений потребуется на скромный взгляд ещё 2 - 3 ТБ.
И считатся это будет наверно дни. на вскидку и без базы данных. Такая работа стоит времени специалиста и за пределами бесплатных консультаций. ИМХО.

Да чё за бред-то? СУБД вполне адекватно могут это обрабатывать, там порядка 2 миллиародов записей (если по килобайту считать), не так и много. Т.е. много, но не запредельно много.

Берёте например Vertica или Virtuoso -- и оно вам всё всосёт.
Да, придётся повозиться с подготовкой данных, но это вполне ожидаемо.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508033
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Александрович.9821831. Речь идет о текстовой неструктурированной информации, или о реляционных данных, хранящихся в текстовом виде?
во втором случае каково количество полей данных?


Файлы представляют собой хранилища слов всех языков мира
те списки слов на разных языках

9821832. Чем вызван такой способ хранения данных?


Дали файлы - сказали решить вопрос с дубликатами и хранением

9821832. Чем отличаются отдельные файлы. (Это последовательно обрезанный поток данных, или это данные с разных источников?)

Это файлы с разных источников ( часто даже с различным способом хранения данных - те нужно будет к каждому файлу писать парсер или свою проверку корректности данных. Учитывая что там еще слова на разных языках то переводить все в UNICODE )

Андрей, мне кажется, это задачка не совсем вам по зубам будет.
Ну всё же по уровню вопросов понятно, что опыта у вас маловато для такого.
Ну, там подсказывать и направлять можно долго, но делать-то всё равно вам.

У вас тут решающим будет вопрос о поддержке юникода в вашем приложении и в СУБД, имейте это в виду В ПЕРВУЮ ОЧЕРЕДЬ.
При чём это будет не просто какая-то поддержка юникода, а ПОЛНАЯ поддержка юникода.

Правда, может не всё так и плохо -- мы же так и не знаем, что там у вас за данные о словах, что там вам с ними надо будет делать, помимо удаления дубликатов (которое кстати также может быть весьма забавной задачкой, поскольку есть слова-омонимы, и вам нужно будет определять, это другое определение того же слова или это вообще другое слово-омоним).
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508034
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня есть подозрение что этих гигабайтных файлах полно всякого
шлака который надо не унифицировать а просто удалять. Сами подумайте.
Ни один писатель в мире больше сотни мегабайт текста не написал.

А здесь речь идет о гигабайтах. Что там за справочники? Что за словари?
Что там за данные? Это больше чем Британская энциклопедия.

Вобщем прошу автора прояснить.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508049
mikron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemarglmikron,

хэширование спасет мир
Не спасёт но делает его немного лутше.
После совпадения хеша надо делать полную проверку. Если сравнивать записи то будет много метаний.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508050
982183
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В однотомном словаре С.И. Ожегова представлены около 57 тысяч слов. В четырехтомном словаре, созданном под редакцией Д.Н. Ушакова, указаны более 85 тысяч слов. В семнадцатитомном словаре современного русского литературного языка, изданного Академией наук СССР, располагается 120 480 слов. В далевском «Толковом словаре живого великорусского языка» представолены более 200 тысяч слов!

Разные словари дают разную оценку словарному составу английского: некоторые источники насчитывают примерно 500 тысяч слов, другие - примерно 400 тысяч. Стоит остановиться на чем-то оптимальном - например, словаре Уэбстера, который насчитывает 425 тысяч слов. По некоторым подсчетам, активный словарный запас у самых начитанных европейцев и американцев насчитывает не более 20 тысяч слов, а пассивный - не более 100 тысяч.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508051
982183
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Другие источники говорят:
По версии GLM, сейчас английский язык насчитывает 1 миллион 4 910 слов. Причем согласно статистике, новое слово в английском языке появляется каждые 98 минут (в день 14,7 слов). А вот миллионный рубеж был преодолен 10 июня прошлого года в 10.22, когда эта компания зафиксировала еще одно новое слово Web 2.0, обозначающее новое поколение всемирной компьютерной сети.

http://www.languagemonitor.com/
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508052
mikron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivДа чё за бред-то? СУБД вполне адекватно могут это обрабатывать, там порядка 2 миллиародов записей (если по килобайту считать), не так и много. Т.е. много, но не запредельно много.

Я не говорил что ДБМС не справятся. Я сказал только скорее всего их применение не оправданна для этой задачи. С чем вы не согласны?
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508063
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mikronMasterZivДа чё за бред-то? СУБД вполне адекватно могут это обрабатывать, там порядка 2 миллиародов записей (если по килобайту считать), не так и много. Т.е. много, но не запредельно много.

Я не говорил что ДБМС не справятся. Я сказал только скорее всего их применение не оправданна для этой задачи. С чем вы не согласны?
Мы сейчас обсуждаем алгоритм решения задачи не зная деталей. Может эта задача действительно
решается хеш-табличкой. Но нам нужен хоть какой-то estimation по поводу "толстого" файла.
Если там - низкая кардинальность то все 150 гиг свернутся в нормальные 200 тысяч слов английского
языка.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508065
Bred eFeM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Александрович., хэширование память и сортировка спасет мир. Cерверок с 512ГБ уже купили/арендовали ?
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508073
mikron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton,

по моему больше высказывается догадок.
Задача же в постановке автора - есть 2тб данных, разбросанных по файлам. Логическая единица информации - запись, распологается одной строкой. Нужно удалить все дебликаты записей. Автор не спрашивает как ему организовать хранение этой информации для последующей обработки. Поэтому любая база - уже ненужные расходы. Кластеры, вертика, террадата и т.д. Все это можно но неоправданно.
Моя грубая оценка:
Любая база данных: доп расходы на хранение записей. Пусть 40 байт служебной информации на запись. При длинне записи в 60 байт мы получим в итоге 4 тб данных в базе. Всего 2^40 / 64 получим 16 милиардов записей.
Что бы убрать дупликатуы будем сортировать. Или есть другие предложения для базы?
Пусть будет сортировка. Значит нам потребуется ещё минимум 4 тб на временные таблицы.
Ну а про время я затрудняюсь даже оценить. Слишком большой разрос от дбмс.
Юниксовские утилиту уже лутше, но uniq работает на отсортированных данных. Ну а sort будет сортировать - во первых это не нужно, во вторых долго, в третьих потребует 4 тб
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508075
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mikronЛюбая база данных: доп расходы на хранение записей. Пусть 40 байт служебной информации на запись. При длинне записи в 60 байт мы получим в итоге 4 тб данных в базе. Всего 2^40 / 64 получим 16 милиардов записей.
Что бы убрать дупликатуы будем сортировать. Или есть другие предложения для базы?
Пусть будет сортировка. Значит нам потребуется ещё минимум 4 тб на временные таблицы.
Ну а про время я затрудняюсь даже оценить. Слишком большой разрос от дбмс.
Юниксовские утилиту уже лутше, но uniq работает на отсортированных данных. Ну а sort будет сортировать - во первых это не нужно, во вторых долго, в третьих потребует 4 тб
Откуда вообще 60 байт? Вроде автор вообще не говорил ничего подобного.

И при чем здесь сортировка?
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508077
Aleksandr Sharahov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mikron,

Слова разных языков, очевидно, различны.
В каждом языке ~ 10^6 слов.
Загрузка в хеш-таблицу одного языка ~ 0.1-1 мин.

Что потребуется дополнительно:
- дать файлам имена в соответственно языку,
- процедура чтения слов языка из файлов,
- процедура записи слов языка в файл.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508078
mikron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если же допустить что у нас 2^34 записей и мы можем адресовать запись одним 64bit словом то получится для хештаблицы потребуется 127 гб памяти.
При колизии хеша нужно проверять всю запись. А значит уже при 1% нужно будет проверить 256 милион записей. Hdd с при чтении в разброс с позиционированием головок при 16 мс получим 2^27 х 2^4 x 2^-10 x 2^-6 x 2^-6 получим 2 ^ 9 часов. После нахождения дупликата его надо удалить. Тут куча вариантов реализаций. Но 600 часов уже kill argument.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508081
Aleksandr Sharahov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mikron,

во-первых, записей никогда не будет больше, чем слов в одном языке ,
во-вторых, они прекрасно лягут в хеш-таблицу в памяти .
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508083
azsx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторКак быть с его толстым файлом который в 150Г ?
sort -u -T temp-directory file.txt > result.txt
Очень давно я чистил базы слов для сео (типа базы кеев пастухова в текстовых файлах, только сам собирал). Команда sort очень быстрая, по сравнению с моими реализациями и в несколько раз быстрее, чем реализации в БД. Для выборки кеев я в БД ваще только минусы вижу.
оффтопик
Как человек, который писал html поиск по главным нескольких десятков миллионов популярных доменов -- крайне рекомендую разобраться в своих кодировках. У азиатов и исламистов тексты к уникоду очень часто не имеют никакого отношения, а вот для сеошников некоторых любые из них важнее, чем немцы.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508084
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Aleksandr Sharahov, ну так вы с самого начала могли решать эту задачу! В чем у вас тогда вопрос?
Если вы можете решить ее через Delphi::hashMap - то решайте.

Но как верно заметил MasterZiv - проверьте локаль для каждой страны. Чтоб при конверсиях
строк не потерять ни одного символа. Это важно.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508085
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Александрович.Есть свободные 3 тб те куда делать временные таблицы есть
Маловато если исходных данных 2 Тб. Но если дублей много, то может и хватит.

ИМХО БД тут лишняя. Алгоритм примерно такой просится:
1-й проход набираем данных сколько в память влезет, сортируем, сохраняем в файл №1, следующая порция - файл №2 и т.д.
Затем слияние сортированных блоков попарно . В процессе слияния дубли выкидываем.
В итоге будет один файл с уникальными отсортированными записями, а дальше его можно в БД, а можно как есть использовать, если надо только читать.

Например при 8 Гб оперативки получим 256 файлов. По загрузке диска: 1+8 циклов чтение-расчет-запись на диск. Для 18 Тб на скорости 100 Мб/сек потребуется 50 часов дискового IO. Можно потоковое сжатие использовать, gzip/deflate, тогда в несколько раз быстрее работа с диском будет и места меньше потребуется.
Первый этап, т.е. первичная сортировка блоков, будет тормозной из-за проца, т.к. там больше проц будет загружен, поэтому его лучше распараллелить по количеству ядер.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508086
Aleksandr Sharahov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton,

я много задач могу решить, но это вовсе не значит, что я должен решать каждую :-)
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508088
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Aleksandr Sharahovmayton,

я много задач могу решить, но это вовсе не значит, что я должен решать каждую :-)
Ну ОК. На самом деле в вашей задаче интересен только 150Гб файл. Все остальное решается
как угодно... sort, uniq, база. И у меня для вас минимум два алгоритма. Было. Сейчас я
думаю что вам с Delphi+MSSQL сам бох велел залить в табличку с опцией IGNORE_DUP_KEY.

Тут я думаю траблы будут другие.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508089
mikron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Aleksandr Sharahovmikron,

во-первых, записей никогда не будет больше, чем слов в одном языке ,
во-вторых, они прекрасно лягут в хеш-таблицу в памяти .
Мне кажется ваше допущение не коректно, что запись равна слову язука. Автор сказал что запись содержит слово языка но не значит что она / запись состоит только из слова.
В любом случае ваше допущение не обяснит как автор набрал 2 тб данных.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508090
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonAleksandr Sharahovmayton,

я много задач могу решить, но это вовсе не значит, что я должен решать каждую :-)
Ну ОК. На самом деле в вашей задаче интересен только 150Гб файл. Все остальное решается
как угодно... sort, uniq, база. И у меня для вас минимум два алгоритма. Было. Сейчас я
думаю что вам с Delphi+MSSQL сам бох велел залить в табличку с опцией IGNORE_DUP_KEY.

Тут я думаю траблы будут другие.
Сорян. Не туда запостил ну вобщем-то к автору.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508091
schi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Жаль, что не удалось услышать начальника транспортного цеха.

Автор так ничего и не сказал, как организованы его 180 петабайт данных, из фраз "проверить дубликаты и скомпоновать данные" "Файлы представляют собой хранилища слов всех языков мира" и "собираюсь писать на Delphi" никак непонятна организация слов в файлах и дубликаты чего ему, автору, надо проверять.
Мне кажется, автору надо установить сумму вознаграждения и написать в форум "Работа".
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508094
Aleksandr Sharahov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mikronAleksandr Sharahovmikron,

во-первых, записей никогда не будет больше, чем слов в одном языке ,
во-вторых, они прекрасно лягут в хеш-таблицу в памяти .
Мне кажется ваше допущение не коректно, что запись равна слову язука. Автор сказал что запись содержит слово языка но не значит что она / запись состоит только из слова.
В любом случае ваше допущение не обяснит как автор набрал 2 тб данных.

Даже если запись занимает 60 байт, то 60 мегабайт в памяти - не проблема.
Плюс таблица 16 мегабайт.

Загрузка данных хеш-таблицу пройдет практически со скоростью чтения данных с диска,
а дубликаты отсеются в процессе загрузки.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508098
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Aleksandr Sharahovmikronпропущено...

Мне кажется ваше допущение не коректно, что запись равна слову язука. Автор сказал что запись содержит слово языка но не значит что она / запись состоит только из слова.
В любом случае ваше допущение не обяснит как автор набрал 2 тб данных.

Даже если запись занимает 60 байт, то 60 мегабайт в памяти - не проблема.
Плюс таблица 16 мегабайт.

Загрузка данных хеш-таблицу пройдет практически со скоростью чтения данных с диска,
а дубликаты отсеются в процессе загрузки.
Это при условии что хэш таблица с результатом будет умещаться в памяти. Если не будет - результата думаю будет не дождаться из-за постоянного свопа на диск.

Тут автору топика вопрос: какой ожидается размер результата после выкидывания дублей?
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508100
Aleksandr Sharahov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TЭто при условии что хэш таблица с результатом будет умещаться в памяти.
Если не будет - результата думаю будет не дождаться из-за постоянного свопа на диск.

Тут автору топика вопрос: какой ожидается размер результата после выкидывания дублей?

Ну почему не будет-то?

10^6 слов * 60 байт + 10^6 слов * 2 коэф * (4+4) байт < 100 * 10^6
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508101
mikron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonОткуда вообще 60 байт? Вроде автор вообще не говорил ничего подобного.
И при чем здесь сортировка?
Автор не говорил, но от чего то надо отталкиватся.
Интересно было бы услышать автора сколько у него записей.
Второй вопрос хорош. Как найти / удалить дупликаты без полной сортировки?
Первый уже упомянутый вариант - хеш. Но не будет хорошо работать на большом кол-ве уникальных данных. Есть другие методы, но умеют ли базы данных такое ? Я так думаю что не умеют. А значит только сортировка. Верно?
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508102
Aleksandr Sharahov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mikronmaytonОткуда вообще 60 байт? Вроде автор вообще не говорил ничего подобного.
И при чем здесь сортировка?
Автор не говорил, но от чего то надо отталкиватся.
Интересно было бы услышать автора сколько у него записей.
Второй вопрос хорош. Как найти / удалить дупликаты без полной сортировки?
Первый уже упомянутый вариант - хеш. Но не будет хорошо работать на большом кол-ве уникальных данных. Есть другие методы, но умеют ли базы данных такое ? Я так думаю что не умеют. А значит только сортировка. Верно?

Не верно, я тут уже ссылку давал в 20736814 , почитай.
Хеш-таблица отсекает 10^6 дубликатов из 2*10^6 объектов за доли секунды.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508106
mikron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Aleksandr SharahovDima TЭто при условии что хэш таблица с результатом будет умещаться в памяти.
Если не будет - результата думаю будет не дождаться из-за постоянного свопа на диск.

Тут автору топика вопрос: какой ожидается размер результата после выкидывания дублей?

Ну почему не будет-то?

10^6 слов * 60 байт + 10^6 слов * 2 коэф * (4+4) байт < 100 * 10^6

По тому что 10^ 6 это не обоснованное допущение.
Запись может содержать слово языка плюс ещё что то, пусть его перевод на другой язык.
Например:
allow;ru;разрешать
allow;ru;позволять
allow;de;erlauben
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508107
mikron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Aleksandr Sharahovmikronпропущено...

Автор не говорил, но от чего то надо отталкиватся.
Интересно было бы услышать автора сколько у него записей.
Второй вопрос хорош. Как найти / удалить дупликаты без полной сортировки?
Первый уже упомянутый вариант - хеш. Но не будет хорошо работать на большом кол-ве уникальных данных. Есть другие методы, но умеют ли базы данных такое ? Я так думаю что не умеют. А значит только сортировка. Верно?

Не верно, я тут уже ссылку давал в 20736814 , почитай.
Хеш-таблица отсекает 10^6 дубликатов из 2*10^6 объектов за доли секунды.
Что конкретно не верно?
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508110
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Aleksandr SharahovDima TЭто при условии что хэш таблица с результатом будет умещаться в памяти.
Если не будет - результата думаю будет не дождаться из-за постоянного свопа на диск.

Тут автору топика вопрос: какой ожидается размер результата после выкидывания дублей?

Ну почему не будет-то?

10^6 слов * 60 байт + 10^6 слов * 2 коэф * (4+4) байт < 100 * 10^6
Мне непонятно откуда цифра 10^6 ? При 10^10 как твоя хэш-таблица отработает? ТС этот момент не пояснил, я не просто так вопрос добавил.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508112
azsx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторЧто конкретно не верно?
В базе пастухова 1 млрд кеев (строк со словами) -- это около 60 гб файл. А ТС оперирует 2 тб данных. То есть в 33 раза больше.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508113
Aleksandr Sharahov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mikronAleksandr Sharahovпропущено...


Ну почему не будет-то?

10^6 слов * 60 байт + 10^6 слов * 2 коэф * (4+4) байт < 100 * 10^6

По тому что 10^ 6 это не обоснованное допущение.
Запись может содержать слово языка плюс ещё что то, пусть его перевод на другой язык.
Например:
allow;ru;разрешать
allow;ru;позволять
allow;de;erlauben


Да все нормально.
Пусть слов в языке 2*10^6 - точно достаточно для любого языка.
Пусть под слово (только слово и ничего кроме) 32 байта - точно достаточно.
Всю остальную хрень не читаем из файла, для отбора дубликатов она не требуется.
Прочитаем ее на этапе формирования выходного файла.


mikronЧто конкретно не верно?

Неверно то, что хеш таблица не справится и нужна сортировка.

Сортировка, может, и потребуется перед выдачей результата, но не для отсева дубликатов.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508115
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>schi, сегодня, 10:40 http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1269329&msg=20736710][20736710]
>...Если не удалось, то значит дубль, если удалось, то записывать слово ...
А если так (для русского словаря слов):
1. берём SQLite
2. создаём таблицы с именами а, б, в ... я и одним текстовым полем
3. читаем исходные файлы по строкам
4. выделяем слова и переводим в нижний регистр
5. наличие слов проверяем в соответствующей таблице (по первой букве слова), нет - дописываем
6. сортируем результат в таблицах
7. сливаем таблицы
насчёт индексов - проверить

Если есть память - вместо таблиц использовать списки
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508116
Aleksandr Sharahov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
azsxВ базе пастухова 1 млрд кеев (строк со словами) -- это около 60 гб файл. А ТС оперирует 2 тб данных. То есть в 33 раза больше.

Это на всех языках, включая числа и другие абракадабры?
Сколько слов на самом большом человеческом языке?
На гигабайты пофиг.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508118
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mikronАвтор не говорил, но от чего то надо отталкиватся.
Интересно было бы услышать автора сколько у него записей.
Второй вопрос хорош. Как найти / удалить дупликаты без полной сортировки?
Первый уже упомянутый вариант - хеш. Но не будет хорошо работать на большом кол-ве уникальных данных. Есть другие методы, но умеют ли базы данных такое ? Я так думаю что не умеют. А значит только сортировка. Верно?
Как вы любите сортировать! Дайте волю - отсортируете всю вселенную а потом выберете unique?

Подумайте на следующей идеей. Вам дан текстовый файл. 150Gb. В формате csv.

У вас на борту - 8Gb оперативы. Операционка съедает порядка 2Гб и полезных
для ваших нужд остается порядка 6Гб. Это и есть эффективное пространство
для игр с хешами.

Экспериментально я устанавливаю (к примеру) что в Delphi hash табличка 4Гб ключей
съедают 6Гб кучи. Накладные расходы тык-скыть.

Далее я решаю порезать 150Gb на куски (примерно одинаковые). Будем называть их
chunks. По 4Гб ключей. Но не линейно сверху вниз по csv. А по хеш-функции (к примеру
md5). Не суть важно какая функция.

Считаем сколько будет чанков.

Код: javascript
1.
150 / 4 = 37,5.



Округляем в большую сторону. 38 чанков. И делаем функцию. Типа.

Код: java
1.
2.
3.
int hash38(string key){
   return mod(MD5(key),38); 
}



Я утверждаю что эта функция мапит key в свой чанк всегда. Тоесть одинаковые
ключи всегда будут в одном чанке.

Далее - дело техники. За 1 проход по 150 Гб файлу мы создаем 38 (попугаев)
дисковых чанков. Чтоб дисковая подсистема не сдохла - буферизируем по максимуму.

Потом все 38 файлов обрабатываем через Delphi::hashTable и сливаем уникальные
в result.csv.

Вы спросите вопрос. А не будет ли повторов ключей между чанками. Я отвечу.
Не будет. На основании свойств моей волшебной функции.

И никакой сортировки. Как вам?
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508119
azsx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторЭто на всех языках, включая числа и другие абракадабры?
Сколько слов на самом большом человеческом языке?
Это реальные строки, которые (в теории) могут искать в поисковых системах. Например:
установка окон в москве
скачать windows бесплатно
и так далее. Выборка, типа:
установк и москв
скач и windows исключить бесплатно
в grep на 60 гб делаются на hdd за 10 минут, на sed за 12. Такой файл логично делить по числу реальных винтов в системе.
---
Мне не понятно, как Вы пришли к выводу, что ТС на 2 тб хранит только уникальные слова всех стран мира.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508120
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
azsxавторЧто конкретно не верно?
В базе пастухова 1 млрд кеев (строк со словами) -- это около 60 гб файл. А ТС оперирует 2 тб данных. То есть в 33 раза больше.
А что это за база "Пастухова"? Кто этот замечательный человек?
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508123
mikron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Aleksandr Sharahovmikron

По тому что 10^ 6 это не обоснованное допущение.
Запись может содержать слово языка плюс ещё что то, пусть его перевод на другой язык.
Например:
allow;ru;разрешать
allow;ru;позволять
allow;de;erlauben


Всю остальную хрень не читаем из файла, для отбора дубликатов она не требуется.

Интересный поворот мысли. Другими словами в моём примере вы удалите все строчки за исключением первой как дубликаты?
Вас ничего не смущяет?
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508124
Aleksandr Sharahov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
azsxЭто реальные строки, которые (в теории) могут искать в поисковых системах. Например:
установка окон в москве
скачать windows бесплатно

Тогда это немного не то, что есть у автора в качестве исходных данных.

azsxМне не понятно, как Вы пришли к выводу, что ТС на 2 тб хранит только уникальные слова всех стран мира.

Напротив, из его слов можно предположить, что у него есть некие тексты на языках народов мира.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508125
azsx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторА что это за база "Пастухова"?
Оффлайн база кеев для сеошников. Полезна для некоторых тематик.
авторКто этот замечательный человек?
Программист. ИНН 920156526734, он ИП https://egrul.nalog.ru/
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508127
azsx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторНапротив, из его слов можно предположить, что у него есть некие тексты на языках народов мира.
Тогда я сдаюсь. Чо то шибко много тб для всех слов в мире.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508128
Aleksandr Sharahov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mikronAleksandr Sharahovпропущено...
Всю остальную хрень не читаем из файла, для отбора дубликатов она не требуется.

Интересный поворот мысли. Другими словами в моём примере вы удалите все строчки за исключением первой как дубликаты?
Вас ничего не смущяет?

Нет, не смущает. Была задача удалить дубликаты - я удаляю.
Будет задача объединить - объединю.
Что не так? :-)
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508129
mikron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonИ никакой сортировки. Как вам?
Зачтено.
Вопрос в том, умеют ли DBMS такие и подобные методы? Я думаю что нет, и это мой аргумент против DBMS для этой задачи.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508130
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonИ никакой сортировки. Как вам?
Может и заработает, только 38 неправильная цифра, больше надо, учитывай служебную инфу и размер страницы 4 кб, т.к. при нехватке памяти все что касается чанка должно постоянно быть памяти, т.е. не должно быть свопа пока в хэш-таблицу грузится один чанк.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508133
mikron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Aleksandr SharahovБыла задача удалить дубликаты - я удаляю.
Что не так? :-)
Вобще-то вопрос был риторический но если вам не непонятно: вы удалили оригинальные данные а не дубликаты


allow;ru;разрешать
и не одно и то же что
allow;ru;позволять
и уж совсем не дубликат
allow;de;erlauben
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508134
Aleksandr Sharahov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mikronAleksandr SharahovБыла задача удалить дубликаты - я удаляю.
Что не так? :-)
Вобще-то вопрос был риторический но если вам не непонятно: вы удалили оригинальные данные а не дубликаты


allow;ru;разрешать
и не одно и то же что
allow;ru;позволять
и уж совсем не дубликат
allow;de;erlauben

Вобще-то, и ответ был риторический, но если вам не непонятно,
то без четкого определения дубликата спорить абсолютно бессмысленно.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508138
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mikronmaytonИ никакой сортировки. Как вам?
Зачтено.
Вопрос в том, умеют ли DBMS такие и подобные методы? Я думаю что нет, и это мой аргумент против DBMS для этой задачи.
DBMS умеет по другому. Он бъет сложным и универсальным ударом который
называется B+Tree. Это дерево. Но особое. Оптимизированное для дисковых
блочных операций. И разумеется оно нелетает без прослойки LRU-подобного
кеша блоков.

По сути табличка с индексом решает эту задачу универсально и квази-линейно
масштабируется до 150 Гиг и до петабайт. Зависит от нашей жадности.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508139
mikron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Aleksandr Sharahovmikronпропущено...

Вобще-то вопрос был риторический но если вам не непонятно: вы удалили оригинальные данные а не дубликаты


allow;ru;разрешать
и не одно и то же что
allow;ru;позволять
и уж совсем не дубликат
allow;de;erlauben

Вобще-то, и ответ был риторический, но если вам не непонятно,
то без четкого определения дубликата спорить абсолютно бессмысленно.
Ну и чудесно, теперь надеюсь вам понятно, что ваше утверждение что хеш-таблица прекрасно справится беспочвенно.
Как некоторые уже писал, зависит от количества уникальных ключей.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508140
Aleksandr Sharahov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mikronAleksandr Sharahovпропущено...
Вобще-то, и ответ был риторический, но если вам не непонятно,
то без четкого определения дубликата спорить абсолютно бессмысленно.
Ну и чудесно, теперь надеюсь вам понятно, что ваше утверждение что хеш-таблица прекрасно справится беспочвенно.
Как некоторые уже писал, зависит от количества уникальных ключей.

Я и не утверждал, что хеш-таблица справится со всеми задачами, которые вы придумаете.

Я лишь считаю, что с задачей автора, как я ее понимаю, хеш-таблица справится.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508141
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TmaytonИ никакой сортировки. Как вам?
Может и заработает, только 38 неправильная цифра, больше надо, учитывай служебную инфу и размер страницы 4 кб, т.к. при нехватке памяти все что касается чанка должно постоянно быть памяти, т.е. не должно быть свопа пока в хэш-таблицу грузится один чанк.
Заработает! Не сомневайся! Ученье Маркса правильно, потому что оно - верно!

Принципиально-то алгоритм рабочий?

А по сабжу... то что ты говоришь - это тонкая настройка структур данных. Я там по тексту упомянул
что на 4Г ключей (по суммарной длине) я резервирую аж 2Г служебной инфы. По моему
это более чем достаточно для всех "гранулярных" структур данных.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508142
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton4Г ключей (по суммарной длине)
Ну откуда вы эти предположения берете? ТС ничего не сказал по этому поводу. Исходи из худшего: все значения уникальны.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508144
Фотография ПЕНСИОНЕРКА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Александрович.,
в словарях практически нет повторений статей по слову(помогала как-то форматировать в ворде 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гб будет много меньше )
при этом получим статистику --а сколько слов в словаре, средняя длина стать
--имя словаря
--язык
--порядковый номер в справочнике
--ключевое слово статьи

ведь может потребоваться пересобирать источники в другом порядке, можно сначала собрать мелочь,
получив единый(ничего не удаляя),а только потом сливать с базовым
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508148
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonПринципиально-то алгоритм рабочий?
Рабочий. При большом количестве ключей надо будет допилить распределение по чанкам.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508149
Фотография ПЕНСИОНЕРКА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonВам дан текстовый файл. 150Gb. В формате csv.
их хотя и не без проблем можно разбить на 15 по 1 гб, хотя если статьи длинные --- частей может быть и меньше

150гб --это не показатель
сколько это записей
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508150
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Aleksandr Sharahovmikronпропущено...

Ну и чудесно, теперь надеюсь вам понятно, что ваше утверждение что хеш-таблица прекрасно справится беспочвенно.
Как некоторые уже писал, зависит от количества уникальных ключей.

Я и не утверждал, что хеш-таблица справится со всеми задачами, которые вы придумаете.

Я лишь считаю, что с задачей автора, как я ее понимаю, хеш-таблица справится.
Нет сомнений что справится. Есть просто разные оценки времени. Алгоритм который
я предложил делает минимум 2 full scan по 150 Гб пространству ключей (построение
38 чанков и работа с каждым из них отдельно).

Сортировка о которой говорили выше в такой постановке не то чтобы не возможна.
Она возможна. Но вангую что под капотом у утилит sort, unique, e.t.c лежит
знаметитая "дисковая сортировка слиянием" (она -же ленточная, она-же merge)
которая перелопатит наши 150 Гиг не один и не два а логарифм ... хер там от какого
числа итераций, количество которых будет определяться эффетивностью первой
фазы.

Поэтому когда мне говорят о сортировке 150 Гиг - я улыбаюсь.

Попробуйте...
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508151
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima Tmayton4Г ключей (по суммарной длине)
Ну откуда вы эти предположения берете? ТС ничего не сказал по этому поводу. Исходи из худшего: все значения уникальны.
Дима так все чики-пики. Я беру worst-scenario!
Я беспокоюсь о том чтобы вы не получили out of memory error.
Все 4 Гига уникальны? Отлично. Они все лягут нормик в хеш-табличку.
Будет 50% дублей? Отлично. Они свернуться на 2-й фазе когда мы отработаем
всех 38 попугаев.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508152
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ПЕНСИОНЕРКАmaytonВам дан текстовый файл. 150Gb. В формате csv.
их хотя и не без проблем можно разбить на 15 по 1 гб, хотя если статьи длинные --- частей может быть и меньше

150гб --это не показатель
сколько это записей
+1

Ваш поинт про сколько записей очень верный! И я его коснусь в моем втором алгоритме.
Который я опишу чуть позже если топик еще будет актуален.

Выше вы пишете про 15 по 1Гб? Вы хотели сказать 15 по 10Гб?
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508155
mikron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonmikronпропущено...

Зачтено.
Вопрос в том, умеют ли DBMS такие и подобные методы? Я думаю что нет, и это мой аргумент против DBMS для этой задачи.
DBMS умеет по другому. Он бъет сложным и универсальным ударом который
называется B+Tree.
Это детали реализации но суть останется - сортировка всех данных. это точно не лучше того что вы предложили.
Интересно что могут предложить монстры оптимизации от DBMS.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508157
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonВсе 4 Гига уникальны? Отлично. Они все лягут нормик в хеш-табличку.
Будет 50% дублей? Отлично. Они свернуться на 2-й фазе когда мы отработаем
всех 38 попугаев.
Изначально озвучено 2 Тб, считай что они все уникальны, ну или упрости до 50%, т.е. 1 Тб уникальных. Какие 4 Гб?

хэш-таблица на 2 Тб имеет право на жизнь, только надо ОС оповестить чтобы она не убила прогу запросившую столько памяти и память с умом использовать, т.е. чтобы не постоянный своп, а нужное в большинстве случаев оказывалось уже отраженным в физическую память.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508158
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mikronmaytonпропущено...

DBMS умеет по другому. Он бъет сложным и универсальным ударом который
называется B+Tree.
Это детали реализации но суть останется - сортировка всех данных. это точно не лучше того что вы предложили.
Интересно что могут предложить монстры оптимизации от DBMS.
Они не сортируют. Они - строют дерево. Согласись - постановка
звучит как-то по другому.

А если ты сделаешь

Код: sql
1.
SQL> SELECT dictinct word FROM fucken150GigTableDictionary


и при этом word будет не проиндексирован - то оптимизатор DBMS (Oracle - к примеру)
автоматически сольет всю выборку в табличное пространство TEMP. Потом отсортирует
теми-же алгоритмами что и мы обсуждали и потом выдаст курсор из этого TEMP
пространства временных упорядоченных данных.

Ничто не ново!

Поэтому безсмысленно спрашивать что дескыть DBMS-вендор предложит. Мы - разрабатываем
задачу. И мы отвечаем за эффективность ее решения.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508160
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TmaytonВсе 4 Гига уникальны? Отлично. Они все лягут нормик в хеш-табличку.
Будет 50% дублей? Отлично. Они свернуться на 2-й фазе когда мы отработаем
всех 38 попугаев.
Изначально озвучено 2 Тб, считай что они все уникальны, ну или упрости до 50%, т.е. 1 Тб уникальных. Какие 4 Гб?

хэш-таблица на 2 Тб имеет право на жизнь, только надо ОС оповестить чтобы она не убила прогу запросившую столько памяти и память с умом использовать, т.е. чтобы не постоянный своп, а нужное в большинстве случаев оказывалось уже отраженным в физическую память.
Ну... здесь без автора трудно что-то спорить и доказывать. Но насколько я понял его первый пост.
2 Тб - это все справочники всех языков. А 150Гб - это просто один из самых толстых справочников.

Нужно-ли гарантировать кросс-уникальность между справочниками? Я не знаю. Скорее всего нет.
Это должно быть гарантировано кодовой страницей. Финские слова не пересекаются со шведскими.

Если я ошибаюсь - то пускай ТС - откомментарит.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508164
Aleksandr Sharahov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Автор говорил о "списках слов на разных языках" и все.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508165
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Делим на чанки 2Терабайта...
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508167
schi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonDBMS умеет по другому. Он бъет сложным и универсальным ударом который
называется B+Tree. Это дерево. Но особое. Оптимизированное для дисковых
блочных операций. И разумеется оно нелетает без прослойки LRU-подобного
кеша блоков.

Первый раз такую трактовку слышу, про оптимизацию с дисками. Не поделитесь источником ?
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508170
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
schimaytonDBMS умеет по другому. Он бъет сложным и универсальным ударом который
называется B+Tree. Это дерево. Но особое. Оптимизированное для дисковых
блочных операций. И разумеется оно нелетает без прослойки LRU-подобного
кеша блоков.

Первый раз такую трактовку слышу, про оптимизацию с дисками. Не поделитесь источником ?
1) Ваша постановка вопроса меня удивляет. Если вы из сегмента It - то вы должны были проходить
курс алгоритмы и структуры данных. Там - дают вводную по деревьям (красные-чорные, бинарные,
тернарные, АВЛ) и в том числе B+Tree, N-того порядка. Последние просто являются
частным случаем предыдущих деревьев при условии что группа узлов (Nodes)
объединяются в дисковый блок (2/4/8/16K) массив и все операции с узлами
делаются в рамках блока. Это дает оптимальное использование I/O.

Один из производителей DBMS их описывает так.
B-tree indexes are the standard index type. They are excellent for highly selective indexes (few rows correspond to each index entry) and primary key indexes. Used as concatenated indexes, a B-tree index can retrieve data sorted by the indexed columns.
Далее по ссылке отрисовывается вся внутренняя структура.

https://docs.oracle.com/database/122/CNCPT/indexes-and-index-organized-tables.htm#CNCPT88834

Детально об этом пишут разные писатели. Джонатан Льюис. Том Кайт.

Решение нашей задачи в рамках DBMS я вижу так:

Код: sql
1.
create table FuckenWordsDictionary(word VARCHAR2(2000) primary key) organization index;



Далее - наполняем этот справочник insert-ами и игнорируем ошибку ORA-00001. Отбрасываем дубли.

Profit.

2) По кешам.

Механизм кеша - это я сказал ниочом и обо всем. Практически все современные
DBMS используют разные варианты кешей. IBM DB2, Postgres e.t.c. А кто не использует
тот дурак и у того нет перформанса.

Поэтому моя фраза о кешах - это попадание пальцем в небо. Так-же как и
"Волга Впадает в Каспийское море".
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508173
schi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
Первый раз такую трактовку слышу, про оптимизацию с дисками. Не поделитесь источником ?
1) Ваша постановка вопроса меня удивляет. Если вы из сегмента It - то вы должны были проходить
курс алгоритмы и структуры данных. Там - дают вводную по деревьям (красные-чорные, бинарные,
тернарные, АВЛ) и в том числе B+Tree, N-того порядка. Последние просто являются
частным случаем предыдущих деревьев при условии что группа узлов (Nodes)
объединяются в дисковый блок (2/4/8/16K) массив и все операции с узлами
делаются в рамках блока. Это дает оптимальное использование I/O.

Один из производителей DBMS их описывает так.
B-tree indexes are the standard index type. They are excellent for highly selective indexes (few rows correspond to each index entry) and primary key indexes. Used as concatenated indexes, a B-tree index can retrieve data sorted by the indexed columns.
Далее по ссылке отрисовывается вся внутренняя структура.

https://docs.oracle.com/database/122/CNCPT/indexes-and-index-organized-tables.htm#CNCPT88834

Детально об этом пишут разные писатели. Джонатан Льюис. Том Кайт.

[/quot]

Ничего не понял. Кайта и Льюиса читал, с деревьями знаком несколько раньше, чем вышли книги Кайта и Льюиса же, и ни разу не слышал про оптимизацию использования деревьев с точки зрения ввода-вывода, поэтому и заитересовался.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508174
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
schiНичего не понял. Кайта и Льюиса читал, с деревьями знаком несколько раньше, чем вышли книги Кайта и Льюиса же, и ни разу не слышал про оптимизацию использования деревьев с точки зрения ввода-вывода, поэтому и заитересовался.
Вся дисковая оптимизация для дисков старого поколения (магнитных) базируется
на уменьшении количества чтений и записей блоков (db_blocks). Сам по себе блок может
варьироваться от 512 байт до 64к. Это зависит от ОС и архитектуры. Поэтому
все структуры данных такие как таблицы и индексы бьются на блоки и читаются
и сериализуются кусками кратными блоку. Это считается ТруЪ для всех DBMS.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508298
schi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonschiНичего не понял. Кайта и Льюиса читал, с деревьями знаком несколько раньше, чем вышли книги Кайта и Льюиса же, и ни разу не слышал про оптимизацию использования деревьев с точки зрения ввода-вывода, поэтому и заитересовался.
Вся дисковая оптимизация для дисков старого поколения (магнитных) базируется
на уменьшении количества чтений и записей блоков (db_blocks). Сам по себе блок может
варьироваться от 512 байт до 64к. Это зависит от ОС и архитектуры. Поэтому
все структуры данных такие как таблицы и индексы бьются на блоки и читаются
и сериализуются кусками кратными блоку. Это считается ТруЪ для всех DBMS.

Да, я знаю, что Волга впадает в Каспийское море, но причем тут B-деревья ? :)
На уменьшении количества операций ввода-вывода направлена любая оптимизация, пока диски не быстрее памяти, увы.

Ждем автора, от него должна информация поступать, а то, может, ему и оптимизация не нужна вовсе.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508319
Bred eFeM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonКак вы любите сортировать! ... табличка 4Гб ключей ... это на 1*10^9 или на 4*10^9 ключей?

Считаем сколько будет чанков. там слова? - а значит буквы - 32*2+1 будет достаточно.
Итого, максимум 1,5*10^9 слова из 20 разных первых символов длиной 5 (байт), которые на основании свойств моей волшебной функции сортируются с выбрасыванием копий не дольше 2х(чтение-запись) диска.

И никакой сортировки. Как вам? И что с этим неупорядоченным 150G "как вам" делать дальше? Индексы строить, хеши считать...
...
Рейтинг: 0 / 0
Работа с большими данными
    #39508384
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я своё мнение кажется сказал в первом посте. Грузить в базу.

А все остальное в топика - это игры разума. И я поддерживаю их ради дискурса.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39510874
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В продолжение топика. Для 150Гб файла в качестве метрики эффективности
алгоритма КМК мы должны брать за основу т.н. Full-Table-Scan (это в терминологии БД).

Или грубо говоря 1 проход чтением по нашему файлу. Full-File-Scan (если мы работаем
со своими самописными алгоритмами). Для краткости - FFS.

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

Как я уже говорил - ленточная сортировка - это сразу более чем несколько FFS.
Ванговать не буду. Это количество зависит от оперативы у вас на борту.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39510885
Aleksandr Sharahov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Можно предложить симбиоз оптимистичного и пессимистичного 20737243 алгоритма.

Сначала оптимистично грузим данные в хеш-таблицу пока не накопится некоторое предельное количество различных ключей, например, 2*10^6.

Если все данные успешно загрузятся без превышения лимита различных ключей, то цель достигнута - остается лишь выгрузить результат в файл.

Если же различных ключей много, например, 128*10^6, то мы рано или поздно достигнем лимит. В этом случае выгружаем промежуточные результаты в 128 файлов, расслоив данные по хеш-коду. Затем очищаем таблицу, загружаем новую порцию, снова расслаиваем и дописываем в те же файлы. Продолжаем до исчерпания исходных данных. На второй фазе алгоритма поочередно грузим каждый из 128 промежуточных файлов в хеш-таблицу (с другой хеш-функцией) и дописываем из нее данные в результирующий файл.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39510887
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Aleksandr Sharahov, +1

Я тоже об этом думал. Но у меня была идея такая. Мы (к примеру) имеем не 1 а аж минимум 3 разных
алгоритма унификации большого толстого грёбаного файла (big-fat-ugly-file (BFUF)).

И во всех трех алгоритмах всегда присутствует первая фаза FFS. Что мы будем делать в эту фазу?
Сразу много всего.
- анализировать сведенья (число строк. средняя длина. количество уникальных на тек.момент,
гистограммы и прочие характеристики текста. Языки кодировки.)
- параллельно строить hash-table или другую структуру данных полезную для distinct of BFUF.
- если при параллельной постройке hash-table мы вышли за какие-то разумные границы
расходов памяти - то процесс анализа продолжаем до конца.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39510895
Alibek B
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Александрович.Есть текстовые данные - порядка 2 тб в виде набора файлов ( файлы от 200 мб до 150 гб )
Задача проверить все файлы и удалить дубликаты ( а так же скомпоновать данные )
Что является записью (по которой выявляются дубликаты)?
Весь файл? Строка? Слово?
Если строка или слово, то необходимости использования БД я пока не вижу.
Нужно проиндексировать записи в имеющихся файлах, упорядочив их по языку и алфавиту.
При наличии индексов работать с этими файлами или выгрузить обработанные и отсортированные данные будет легче.
А удалять из середины 150ГБ файла несколько строк-дубликатов может быть накладно.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39510906
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alibek B.А удалять из середины 150ГБ файла несколько строк-дубликатов может быть накладно.
...
Рейтинг: 0 / 0
Работа с большими данными
    #39518643
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Всем заинтересованным.

Тема имеет логическое продолжение здесь Тяпничная унификация
...
Рейтинг: 0 / 0
112 сообщений из 112, показаны все 5 страниц
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Работа с большими данными
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]