Представлен (https://www.cockroachlabs.com/blog/cockroachdb-1dot1/) выпуск распределённой СУБД CockroachDB 1.1 (https://www.cockroachlabs.com/), ориентированной на создание высоконадёжных географически распределённых хранилищ, отличающихся высокой живучестью и не зависящих от сбоев дисков, узлов и центров обработки данных. CockroachDB гарантирует целостность ACID-транзакций, предоставляет возможность использования SQL для манипуляции с данными, позволяет вносить изменения в схему хранения на лету, поддерживает индексы и внешние ключи. Код проекта написан на языке Go и распространяется (https://github.com/cockroachdb/cockroach/) под лицензией Apache 2.0. Подробнее с особенностями CockroachDB можно познакомиться в анонсе первого выпуска (https://www.opennet.ru/opennews/art.shtml?num=46529).Основные новшества (https://www.cockroachlabs.com/docs/releases/v1.1.0.html) выпуска CockroachDB 1.1:
- Расширены средства для миграции на CockroachDB с различных реляционных и NoSQL СУБД. Добавлена возможность импорта больших объёмов данных (терабайты), оформленных в формате CSV. В том числе возможно распараллеливание загрузки таких файлов - файл разбивается на части, которые копируются на разные узлы кластера и загружаются в параллельном режиме. Кроме того, улучшена поддержка миграции SQL-дампов из PostgreSQL;- Добавлена поддержка типов для работы с массивами (ARRAY) и UUID;
- Добавлен интерфейс для наглядного наблюдения за активностью в кластере, анализа выполняемых в данный момент операций и их влияния на производительность. Доступна таблица длительно выполняемых работ (изменение схемы, импорт CSV, создание/восстановление резервных копий) с возможностью оценки прогнозируемого времени операции и функцией принудительной отмены/приостановки задания;
- В CLI-интерфейс добавлены команды "SHOW QUERIES", "SHOW JOBS" и "SHOW SESSIONS", позволяющие просмотреть выполняемые в данный момент SQL-запросы, длительные работы и активные клиентские соединения, команды "CANCEL QUERY" и "CANCEL JOB" для отмены запросов и работ, команда "SHOW BACKUP" для просмотра содержимого резервной копии, а также команды "PAUSE JOB" и "RESUME JOB" для временной приостановки работ;
- Добавлена новая утилита init для быстрого развёртывания (https://www.cockroachlabs.com/docs/v1.1/manual-deployment.html) многоузлового кластера;- Проведена работа по увеличению производительности для нагрузок, свойственных для облачных систем. Нагрузочное тестирование, проведённое через выполнение большого числа параллельных операций над данными в формате ключ/значение, показало снижение средней задержки выполнения операции на 5 мс (13%), при том что 95% запросов уложились в 17 мс (на 11% лучше), а пропускная способность возросла на 14% (достигнут уровень в 44 тысячи запросов в секунду). В 17 раз ускорено выполнение операции восстановления из резервной копии. Введён в стой 128-узловой кластер для тестировния CockroachDB и выявления регрессий в производительности выполнения операций OLTP.
URL: https://www.cockroachlabs.com/blog/cockroachdb-1dot1/
Новость: http://www.opennet.ru/opennews/art.shtml?num=47386
кто бы рассказал, ЧТО, блин, на самом деле байда там хранит... Вряд ли ведь они закидывают пачки денег под дверь, в надежде когда-то получить полезный предмет, совсем на китайцев непохоже.
В последнее время часто вижу какую-то предвзятость и паранойю к китайцам в IT. Интересно, почему?
> В последнее время часто вижу какую-то предвзятость и паранойю к китайцам в
> IT. Интересно, почему?Некоторые несознательные товарищи, которые не совсем и даже совсем нам уже не товарищи, бросают тень на репутацию Великого Братского Китайского Народа,
товарищ шаосяо!
> Некоторые несознательные товарищи, которые не совсем и даже совсем нам уже не
> товарищи, бросают тень на репутацию Великого Братского Китайского Народа,
> товарищ шаосяо!Ноуп, я не в этом смысле. Интересно, почему именно в IT такая предвзятость.
Не только в ИТ, поверь.
потому что все остальное они примерно так же делают.
Почитай, если сумеешь найти не квадратиками, про катастрофу в Дарьяле - особенно, про вторую. Все что тебе нужно знать про отношение китайцев к безопасности, включая не только свою, к уровню проработки сложных необычных проектов, к подходам...
Но вот песка в цемент они насыплют ровно столько, сколько полагается по технологии, и не потому что не хотят сэкономить, а потому что хрен его знает. Поэтому то, что уже построено, будет стоять вечно.
А где ты тут предвзятость нашёл? Вроде бы наоборот, было предположение, что байду вменяем и использует эту базу каким-то вменяемым образом.Но если в общем - их закрытость (точнее - привычка игнорировать всё не-китайское, особенно различия менталитета) её неизбежно порождает. Не хочешь предвзятости - старайся, чтобы тебя понимали, но китайцам это, кажется, не нужно абсолютно. Результат закономерен. Оно не только в IT, оно везде так. Те их моих знакомых, кто с ними работал, в одном сходятся - их хрен поймёшь.
Ну как бы у них свой китайский мир, по численности носителей языка англосаксов давно переплюнули. Так что про закрытость это вы зря, им просто пофиг на всех остальных
> Так что про закрытость это вы зря, им просто пофиг на всех остальныхим не пофиг, они, в отличие от вас, жрать себе в ответ на "cмешные санкции" не запретили, и бомбить свой аналог Воронежа не собираются.
У них достаточно плохо с ключевыми технологиями - копировать получается, самим придумывать с нуля - только там, где это не требует особо думать головой (мелкие микросхемы уже научились сами именно разрабатывать, серьезного ничего полностью своего - нет). У них очень хреново с инструменталкой, и вообще с промышленностью группы A. Со сложной химией. И еще наверняка много с чем.
И они, как и все, закупают все недостающие технологии и инструменты в странах первого мира, деньги на это берут ровно там же, в первом мире, и, по результату, с этим первым миром весьма плотно завязаны. И стараются эти связи расширять, где могут. Получается не всегда, но нельзя говорить что они не пытаются.С софтом все то же самое.
Что мы, собственно, и видим на примере ман..вошьей дебе - не оставили где-то в недрах китайского сайта, а вывалили в паблик, старательно перевели документацию, распихали куда могли анонсы - то есть вполне себе в духе всего остального мира готовы сотрудничать.
При этом внутри используют вполне стандартные технологии, выложенные другими - не сами придумали. "у этих белых макак так принято? Ну ок, значит наверное и нам так надо, если мы зависим от их кусков кода и их разработок."а вот там где не зависят - хрен ты документацию не квадратиками получишь. Или вообще "заплатите нам за разработочку, и получите в готовом виде, а что там как внутри - мы вам не расскажем, да и зачем вам?"
Один поисковик сожрёт минимум несколько петабайт для хранения копий интерента на дискетке.
> Один поисковик сожрёт минимум несколько петабайт для хранения копий интерента на
> дискетке.только эта база явно не для хранения копий интернета (им совершенно не нужна суперотказоустойчивость, потеряется - скачает заново, да и обращений к этим копиям крайне мало. sql тут не нужен совсем).
И не для информации о рекламных кликах - там слишком много insert/s, а тут явно сказано что они не для этого.
Какие-то детали поисковой системы могут, конечно, но как в них искать-то, полнотекстового поиска в этой штуке не заявлено, значит он у байды отдельно в чем-то другом живет.так что скорее всего, что-то совсем другое. Например, данные user accounts (оно же умеет "поиск станет лучше, если вы загрузите в поисковую систему свой паспорт и отпечатки пальцев"? )
Ошибаешься по всем пунктам...> только эта база явно не для хранения копий интернета (им совершенно не нужна суперотказоустойчивость, потеряется - скачает заново, )
По таким базам строят поисковые индексы и если из БД что-то пропадает, то однажды в индекс может не попасть какой-то топовый сайт. Поисковикам подобные фейлы наносят большой репутационный ущерб. Ну и "гарантии" СУБД существенно влияют на частотность обновления индексов.
> ... sql тут не нужен совсем ...
Для работы с СУБД всё равно нужен какой-то язык и SQL в качестве одного из ~ вполне подходит. Это в принципе ни к чему не обязывает, в частности под подмножеством SQL и кастомными расширениями можно спрятать даже совсем нереляционные СУБД и так делают везде.
> И не для информации о рекламных кликах - там слишком много insert/s, а тут явно сказано что они не для этого.
Как раз сказано обратное, т.е. СУБД отдельно поддерживает большие очереди. Вообше эта СУБД имеет большой throughput по записи хотя бы из-за распределённости.
> Какие-то детали поисковой системы могут, конечно, но как в них искать-то, полнотекстового поиска в этой штуке не заявлено, значит он у байды отдельно в чем-то другом живет.
Ты что, совсем тугой? Если бы было можно взять СУБД и сделать на основе FTS поиск по вебу, то сейчас имели бы дохерища поисковиков, но этого нет. Построение поискового индекса это довольно сложный, алгоритмоёмкий и многостадийный процесс...
> да и обращений к этим копиям крайне мало.
... и трогают все страницы в базе. Какие-то чаще, какие-то реже - всё зависит от популярности ресурса и вычислительных возможностей.
> так что скорее всего, что-то совсем другое. Например, данные user accounts ...
И другое наверняка тоже, поддерживать несколько СУБД для разных целей накладно.
> Ошибаешься по всем пунктам...много поисковых систем-то видел вживую?
> По таким базам строят поисковые индексы
по каким "таким"? По "базе" копий всего интернета - никаких индексов обычно не строят. Она предназначена для кнопки "посмотреть сохраненную копию", и для внутренних проверок/ловли блох, а больше ни для чего. Потому что всегда есть оригинал, а если он изменился - то и тем более надо его использовать. Кнопку эту нажимают исключительно редко, обращений к этим архивам около нуля.
Даже clue snippets добываются, вероятнее всего, не оттуда, слишком долго и нудно, а лежат где-то отдельно, поближе к поисковому индексу.> Для работы с СУБД всё равно нужен какой-то язык и SQL в качестве одного из ~ вполне
> подходит.язык в котором нет нечеткого поиска - не считая специфических расширений - нафига он там нужен?
> Это в принципе ни к чему не обязывает,
не обязывает, но в тараканьей системе никакого другого языка нет. Что говорит нам о том, что байда использует ее где-то, где есть банальные табличные формы и удобны обычные sql-запросы. А судя по прослойкам совместимости - можно предположить, что для чего бы ее не использовали, но раньше ЭТО хранилось в postgres ;-) Это уж точно не поисковая база.
> Если бы было можно взять СУБД и сделать на основе FTS поиск по вебу
оно в первом приближении примерно так и сделано. Сюрпрайз, ага. (хотя скорее современные fts сделаны по мотивам, с опозданием на десять лет, а не наоборот)
Правда то что тебе, видимо, представляется при слове "субд", немножко непохоже на то, что там навернуто у тех, о ком кое-что мне известно. Но безусловно, это хоть и странная, но все ж таки база данных, и у нее есть management system.
Поверх этого есть алгоритмы ранжирования и фильтрации, но они именно поверх.дохренища поисковиков мы не поимели (собственно, поимели, в далекие годы доткомов, только долго они не жили) потому что эта хреновина адово дорогая, и прокормить ее на свои деньги невозможно, а на деньги спекулянтов - сложно (потому что первое, о чем тебя спросят - а зачем давать деньги твоему ненадежному стартапу, когда можно просто прикупить акций гугля).
Ничего волшебного в поисковых системах нет. Поиск Рамблера написал один человек, без денег и ресурсов, злоупотребляя рабочим временем, просто потому что ему было интересно (потом уволился, и написал с нуля уже полноценно-морфологический, снова один. Потом, правда, умер.)
> много поисковых систем-то видел вживую?Некоторое колв-о отличное от нуля.
> По "базе" копий всего интернета - никаких индексов обычно не строят.
Не неси чуши. Ну ладно, сверкни интеллектом и расскажи откуда берут данные для построения индексов.
> язык в котором нет нечеткого поиска - не считая специфических расширений - нафига он там нужен?
В SQL есть только одна неустранимая штука - декларативность. Всё остальное к нему прикручивается без проблем если нужно. Можешь посмотреть в том же Postgres как это делают.
> не обязывает, но в тараканьей системе никакого другого языка нет. Что говорит нам о том, что байда использует ее где-то, где есть банальные табличные формы и удобны обычные sql-запросы.
Ты не знаешь что там есть внутри байды, а видишь только некий продукт который они дают и продают конечному потребителю. Внутри могут быть какие угодно расширения или вариации этой СУБД. В любом случае все твои бредни на счсёт сценария использования SQL это всего лишь бредни.
> оно в первом приближении примерно так и сделано.
Оно даже в первом приближении так не сделано. Цели у FTS и у веб поиска в принципе разные.
> Ничего волшебного в поисковых системах нет. Поиск Рамблера написал один человек...
И от чего же Рамблер в итоге оказался в заднице? Наверняка же сглазили, а не потому, что не потянул гонку RnD для поиска и его инфраструктуры.
> В SQL есть только одна неустранимая штука - декларативность. Всё остальное к
> нему прикручивается без проблем если нужно. Можешь посмотреть в том жетолько сам sql для такой задачи - не нужен. Совсем. Спрашивается - ну и из какого пальца ты сделал выводы, что представленная хрень используется для поискового индекса, только вот злые китайцы не показали тебе самое главное?
> Ты не знаешь что там есть внутри байды, а видишь только некий
не знаю, но не вижу смысла придумывать что продукт, очевидно не пересекающийся по назначению с поиском, внезапно, именно для него используется.
> Оно даже в первом приближении так не сделано. Цели у FTS и
> у веб поиска в принципе разные.ну же, ну же, в чем этот принцип?
>> Ничего волшебного в поисковых системах нет. Поиск Рамблера написал один человек...
> И от чего же Рамблер в итоге оказался в заднице? Наверняка жеРовно от того же, от чего, если корову меньше кормить и больше доить, она рано или поздно дохнет.
То есть "благодаря" тем милым людям, которые у нас называются "инвесторы", и ничерта не понимают в том, во что инвестируют. Поэтому все портят. Забавно, что вы не в курсе истории, получившей изрядную известность в этих ваших интернетах, поскольку было кому рассказывать.
В Яндексе не было гениального программиста, те кто создавали раннюю версию с морфологией, довольно быстро вообще ушли в туман, зато был гениальный менеджер, который умел добывать деньги для проекта, не отдавая управления, и сам хорошо понимал, как устроено то, чем он управляет - поэтому и умел выкарабкиваться после системных ошибок (их было). Рамблеру с подобным человеком не повезло.
"Whatever the missing mass of the Universe is, I hope it's not in cockroaches"
Терабайты в CSV?
// вышел в окно
Ну, терабайт не видел, а вот десятки гигабайт - да (не с этой штукой). Оно правда бывает в дикой природе и вполне нормально работает. Уж не знаю, откуда их брали.
А что не так? Всё экономней, чем SQL-дамп.
> А что не так? Всё экономней, чем SQL-дамп.после вот этого:
"
Из ограничений CockroachDB отмечается плохая пригодность для решений, требующих очень низкого времени отклика при выполнении операций записи и чтения. CockroachDB также плохо адаптирован для нагруженных систем обработки аналитической информации
"
передача данных объемами терабайты и форматом csv действительно, удивлять не должна...
Ну логично - отказоустойчивое, но неспешное и не любящее особо навороченные запросы...
> Терабайты в CSV?это единственный стандартизированный (всеми кроме microsoft ;) формат для обмена данными, что тебе не так?
китайцы, очевидно, переливают свои постгрезы (а может и ораклы) в эту штуку - и, разумеется, сделали чтобы это работало.
формат этот для обмена данными крайне неудобен.
годен только для передачи самых простых, примитивных наборов.
Ну назови более удобный в контексте обмена данными между существующими СУБД.
Dblink, штатный экспорт импорт, промежуточные базы(sqlite), xml
> Dblink, штатный экспорт импорт, промежуточные базы(sqlite), xmlштатный совместим только сам с собой, и часто совершенно не является эффективным, тем более на сверхбольших объемах
промежуточная база на энцать терабайт в sqlite, не умеющем partitioning - смешно
xml на энцать терабайт - это даже не смешно, это грустно, что кому-то вообще в голову приходит.но, конечно же, csv никуда не годится, ты знаешь много новых модных слов.
>> Dblink, штатный экспорт импорт, промежуточные базы(sqlite), xml
> штатный совместим только сам с собой, и часто совершенно не является эффективным,
> тем более на сверхбольших объемах
> промежуточная база на энцать терабайт в sqlite, не умеющем partitioning - смешно
> xml на энцать терабайт - это даже не смешно, это грустно, что
> кому-то вообще в голову приходит.
> но, конечно же, csv никуда не годится, ты знаешь много новых модных
> слов.Сверхбольшие объемы данных - передавать вообще не надо. Если у вас часто возникает такая задача- значит вы что-то плохо спроектировали.
>Сверхбольшие объемы данных - передавать вообще не надо.Ну да - а если ты ходишь в памперсах, то должно быть весь мир - тоже :-)
>Если у вас часто возникает такая задача- значит вы что-то плохо спроектировали.
Ну ничего карапуз, скоро ты окончишь школу и изменишь этот говённый мир к лучшему!
Я в тебя верю!
Есть СУБД mysql и есть СУБД postgres, как ты собираешься передать между ними данные с помощью dblink, sqlite, xml? А вот с форматами sql и csv обе СУБД умеют работать напрямую. И не только они.
> Есть СУБД mysql и есть СУБД postgres, как ты собираешься передать между
> ними данные с помощью dblinkВас на поисковике забанили?
, sqlite, xml? А вот с форматами
> sql и csv обе СУБД умеют работать напрямую. И не только
> они.Ну, с примитивными данными да...
> Вас на поисковике забанили?Если тебе будет так легче, то представь, что забанили. По сути ответ будет или опять смайликоизвержение начнется?
Если у какого-то неумного человека, возникает потребность передавать большие объемы данных между разными СУБД и он, вместо чтения документации лезет умничать на форуме - то ему вероятно следует освоить работу с базой через ODBC. Это универсальный механизм, который позволяет прозрачно связывать достаточно разнообразные технологии и платформы.Про себя - скажу: у меня не возникает потребности передавать данные между mysql и postgres потому что архитектуры которые создаю я - работают изначально правильно. Я не гоняю терабайты данных из одной базы в другую ни в каком формате.
В них есть dblink, и ваша проблема- высосана их пальца.
Ну как и ожидалось, куча трёпа не по задаче, рассказы, что тебе такая задача не нужна(то есть ты вообще без понятия как ее решать), а по сути ровно ноль. Ну хоть смайликов не наставил и на том спасибо.
Почему вы считаете что ваша задача- осмысленна?
Я вам сказал как ее можно решить. Вы этого не поняли.
При этом я - оказывается говорю не относящиеся к делу вещи.
Типичный голубь, и вы близки к победе :)
> Почему вы считаете что ваша задача- осмысленна?
> Я вам сказал как ее можно решить. Вы этого не поняли.Если ты неспособен держать нить дискуссии в голове, то я тебе напомню. Речь шла о возможных форматах файлов для передачи данных между различными РСУБД. В качестве варианта формата файла ты предложил в том числе dblink, который вообще ни разу не формат файла, ну ладно. Далее тебе было предложено продемонстрировать, как с помощью dblink перенести данные из мускула в постгрес или наоборот. Вместо ответа на этот конкретный вопрос ты начал вилять задницей, то посылая в гугл, то вообше рассказывая о ненужности передачи данных. То бишь на вопрос не ответил.
> При этом я - оказывается говорю не относящиеся к делу вещи.Именно.
> Типичный голубь
Как самокритично.
> и вы близки к победе :)
Да нет, я "победил" еще тогда, когда ты вместо ответа начал посылать в поисковики, а последние посты это уже из категории "глумление над трупом".
>[оверквотинг удален]
> ты начал вилять задницей, то посылая в гугл, то вообше рассказывая
> о ненужности передачи данных. То бишь на вопрос не ответил.
>> При этом я - оказывается говорю не относящиеся к делу вещи.
> Именно.
>> Типичный голубь
> Как самокритично.
>> и вы близки к победе :)
> Да нет, я "победил" еще тогда, когда ты вместо ответа начал посылать
> в поисковики, а последние посты это уже из категории "глумление над
> трупом".Ну успехов :)
> DblinkЭто не формат представления данных, а модуль который ходит в другие СУБД SQL-ем или другим поддерживаемым методом целевой СУБД.
прежде того, как вы начнете решать вопрос о формате - вы должны решить вопрос о целесообразности и способе.Во первых - данные не надо передавать. И большие объемы оных - тем более.
Это тратит время и деньги. Если есть возможность НЕ ПЕРЕДАВАТЬ данные- следует пойти этим путем.
Если же вам не удается избежать отказа от передачи данных - то лучше всего делать передачу без "форматов", непосредственно делая нечто в таком духе:
"insert as select from dblink" (c)
Если у вас нормальная современная СУБД - у вас вероятнее всего есть такая технология в СУБД. Даже в постгрес и мускуле она есть (не так хорошо как в oracle, но все же).Гражданин, задавший вопрос какие форматы лучше CSV - просто не понимает проблемы. Он никогда не сталкивался с такими проблемами в серьез, и по этому ничего кроме CSV не понимает.
Он не понимает что данные- передавать не надо. Ни в каком формате. Он не понимает что передавать данные нужно при любой возможности без промежуточных преобразований. Поскольку любое каждое преобразование- это потеря времени и денег.и если у вас есть возможность "передать данные" не передавая их физически или не используя любой "формат" - это лучший выбор.
> Он не понимает что передавать данные нужно при любой возможности без промежуточных преобразований.Т.е. данные нужно передавать в формате хранения на накопителе? На самом деле это ты не понимаешь, что у данных нет конкретного единственного формата представления, даже внутри более-менее нетривиальной СУБД существует несколько вариантов представления данных в зависимости от уровня погружения к носителю.
Точно так же дело обстоит и с обменом данными - их укаковывают в какой угодно подходящий формат для решения задачи. Иногда бывает удобен и CSV.
> Он не понимает что данные- передавать не надо.
Ты сейчас пытаешься потрахать людям мозги и увести обсуждение в какую-то другую плоскость. Давай тогда более радикально поменяем тему: ты не понимаешь, что данные создавать вообще не нужно в больших объёмах, любое создание данных приводит к затратам на хранение.
>[оверквотинг удален]
> представления, даже внутри более-менее нетривиальной СУБД существует несколько вариантов
> представления данных в зависимости от уровня погружения к носителю.
> Точно так же дело обстоит и с обменом данными - их укаковывают
> в какой угодно подходящий формат для решения задачи. Иногда бывает удобен
> и CSV.
>> Он не понимает что данные- передавать не надо.
> Ты сейчас пытаешься потрахать людям мозги и увести обсуждение в какую-то другую
> плоскость. Давай тогда более радикально поменяем тему: ты не понимаешь, что
> данные создавать вообще не нужно в больших объёмах, любое создание данных
> приводит к затратам на хранение.Вы такой забавный. Я искренне поддерживаю Ваше желание оказаться правым. Вы правы. Ваше представление о сути проблемы - правильное. Не сомневайтесь в нем. Успехов Вам...
Каждая таблица в базе данных очень проста и там только примитивные наборы. А ты ж, гляди, большие таблицы существуют!
> Каждая таблица в базе данных очень проста и там только примитивные наборы.Да что вы говорите... :)
> А ты ж, гляди, большие таблицы существуют!
Не, ну если какой-то альтернативно одаренный гений пихает в БД фильмы в виде блобов, то кто ему доктор. А в большинстве случаев в таблицах хранится действительно примитивный набор данных: строки, числа, даты. Но ты можешь поделиться с нами своим опытом хранения чего-то непримитивного, уверен, будет как минимум забавно.
> Не, ну если какой-то альтернативно одаренный гений пихает в БД фильмы в
> виде блобов, то кто ему доктор.Обгадить то что не понимаешь.. так себе метод :)
Ну так не томи, поделись уже примерами непримитивных данных, для которых формат csv плохо подходит. А тока пока от тебя только "глубокомысленные" высказывания со смайликами поступают.
LOB, передача базы между СУБД.
> LOBУточни, что из этого https://en.wikipedia.org/wiki/LOB ты имел ввиду. И каким образом это связанно с данными(не внутренним форматом файла СУБД), хранящимися в таблицах.
> передача базы между СУБД.
Передача базы это у тебя данные? Ты вообще смысл вопросов понимаешь?
>> LOB
> Уточни, что из этого https://en.wikipedia.org/wiki/LOB ты имел ввиду. И каким образом это
> связанно с данными(не внутренним форматом файла СУБД), хранящимися в таблицах.Уточняю: Вы тролль в запущенной стадии. LOB в контексте вопроса может быть только такой:
https://ru.wikipedia.org/wiki/LOB>> передача базы между СУБД.
> Передача базы это у тебя данные? Ты вообще смысл вопросов понимаешь?Описание данных - это часть данных. Когда вы передаете данные вместе со структурами- проще всего - передать целиком базу. Вы этого не знали?
Хотя я подозреваю что даже не задумывались об этом...
> всеми кроме microsoftБольше небылиц.
И что такого? В тех же графовых субд максимальная скорость импорта из csv и реально лютая (у нео4ж 250млн зап за 5 минут)
> И что такого? В тех же графовых субд максимальная скорость импорта из
> csv и реально лютая (у нео4ж 250млн зап за 5 минут)я просто оставлю это здесь:
/(?:(?:[^,"]*(?:"[^"]*")*)*,){3}((?:[^,"]*(?:"[^"]*")*)*),/(c) не мое, подсмотрел
sqlite, кстати, такое не может, тоже предлагают использовать херню на php(sic!) парсящую xml(ooops...)
https://sqlite.org/cvstrac/wiki?p=ImportingFiles
Регэкспом? Это что за самоубийцы? Вроде ж на абсолютно любых языках есть нормальные парсеры...
> Вроде ж на абсолютно любых языках есть нормальные парсеры..."нормальный парсер" csv не использующий что-то похожее (этот, если кому неочевидно, выковыривает четвертое (вроде ;) поле из несферического в вакууме csv - где могут быть кавычки в тексте, и двойные тоже, пробелы без кавычек, запятые внутри поля и прочие радости жизни) - ну-ка, покажите-ка?
А то вот "нормальный парсер" той же sqlite часто не может прочитать ее собственный экспорт - откуда и берутся идиотические идеи использовать php и xml.
>ну-ка, покажите-ка?Да легко
https://golang.org/src/encoding/csv/reader.go
Никаких регексов, парсит CSV соответствующий RFC 4180, то бишь "могут быть кавычки в тексте, и двойные тоже, пробелы без кавычек, запятые внутри поля и прочие радости жизни"А если почитаешь сам RFC 4180, то найдешь там BNF грамматику для этого формата, используя которую, можно генерировать парсеры для нужного ЯП при помощи соответствующего софта.
> Да легко
> https://golang.org/src/encoding/csv/reader.goв отличие от regex - который я могу проверить просто внимательно на него глядя, здесь триста (ну ладно, полтораста за вычетом комментариев) строк кода (использующих полмиллиона из других модулей), который проверифицировать я не осилил, не настолько хорошо понимаю go, соответственно - давайте еще ваши восемсот строк тестов, подтверждающих, что этот код таки справится с несферическим в вакууме csv. Я надеюсь, в "нормальном языке" принято их писать? ;-) то что они знали про excel, конечно, хороший признак.
так что я рад, конечно, за go-писателей, что у них есть подобная хренотень в библиотеке, но самому вручную реализовывать конечный автомат по одному символу, а потом еще спотыкаться о битые файлы отдельно - очень не хотелось бы. Надеюсь, оно хотя бы быстрее сишного pcre?
> А если почитаешь сам RFC 4180,
это отдельная тема - например, пункт 6 там в принципе не нужен и не всеми выполняется.
Насколько несферический в вакууме csv будет ему соответствовать, я не берусь угадать.
> триста (ну ладно, полтораста за вычетом комментариев) строк кодаПарсящие регекспы согласно RFC, корректно обрабатывающие комментарии в csv, генерирующие гораздо более осмысленные и информативные ошибки, в случае некорректности CSV. Сопровождённые комментариями, то есть отладка кода или привнесение в него новых возможностей возможны без переписывания всего кода заново.
> использующих полмиллиона из других модулей
Регекспы используют libpcre или, иногда, какую-нибудь альтернативу. Сколько там строк в libpcre если посчитать с зависимостями? Ты _их_ проверифицировал?
> самому вручную реализовывать конечный автомат по одному символу, а потом еще спотыкаться о битые файлы отдельно - очень не хотелось бы
Регекспы, спотыкаясь о битые файлы, ведут себя гораздо более непредсказуемо. Отлаживать регекспы, с тем чтобы они корректно вели себя на некорректно сформированных данных -- это просто самоубийство. А ведь ещё хочется, чтобы парсер указывал на ошибку и пояснял, в чём она состоит -- если он не делает этого, то выходит очень весело, когда я выдрал откуда-то данные, засунул в парсер, а парсер сфейлился сказав лишь "Incorrectly formed data". Как я могу отладить после этого свой код, генерящий csv? Просматривать полмиллиона строк csv глазами в поисках ошибки? Разбивать этот кусок данных на отдельные строки, и смотреть на какой из них сфейлится парсер? А если в этой строке несколько сотен отдельных записей?
Я на своём опыте знаю, чем заканчиваются подобные истории с парсерами на регекспах -- мне приходится отлаживать сразу и регексп, и csv, и исходные данные из которых csv генерируется, и генератор csv. Отлаживать только для того, чтобы понять в каком месте возникает ошибка.> самому вручную реализовывать конечный автомат по одному символу
Зачем самому? Есть готовый код на github'е. Если тебе неинтересно реализовывать конечные автоматы, то есть люди, которым это интересно. Я, например, всегда с удовольствием. Я всегда выискиваю причины, по которым тот или иной регексп следовало бы заменить на самостоятельную реализацию, потому что если причины есть, то можно наслаждаться написанием конечного автомата, с осознанием того, что я не бесцельной мастурбацией занимаюсь, а делаю полезное дело.
> Парсящие регекспы согласно RFC, корректно обрабатывающие комментарии в csvтак тебе не надо "согласно rfc", если ты (надеюсь) не писатель процитированного кода, призванного осчастливить всех.
Тебе надо согласно тому бреду, который породил очередной cvs export.Комментарии? А как их корректно обрабатывать? Я вот вырезаю нафиг - что еще с ними делать, если файл не глазами смотришь?
> Регекспы используют libpcre или, иногда, какую-нибудь альтернативу. Сколько там строк в
> libpcre если посчитать с зависимостями?ее тестируют, да ;-) Мне вот и интересно, у писателей либ для "нормальных языков" есть такая практика, или "у них все работает"?
Ну и я вовсе не призываю пользоваться regex вместо посимвольного конечного автомата (конкретно этот вообще для другого был придуман) - я привел его просто чтобы в одной строчке сразу показать, что разбор csv - на самом деле довольно непростая и не очень-то быстрая процедура. (если что, этот пример - конечный автомат, записанный, постфактум, в виде regexp'а - хрен иначе такое придумаешь)
Впрочем, sql dump, нормальный, не extended insert какой, и с правильными кавычками, парсить ничуть не лучше. А размер у него изрядно больше за счет ненужных sql'ных конструкций.
>> Парсящие регекспы согласно RFC, корректно обрабатывающие комментарии в csv
> так тебе не надо "согласно rfc", если ты (надеюсь) не писатель процитированного
> кода, призванного осчастливить всех.
> Тебе надо согласно тому бреду, который породил очередной cvs export.И? Чем регексп в такой ситуации будет лучше? Если те, кто писал код генерящий csv не ориентировались на rfc, то ещё менее вероятно, что они ориентировались на наш наколенный регексп. И что делать в такой ситуации -- вообще нет никакого единого решения. Иногда в интерактивном режиме в текстовом редакторе приходится приводить csv во вменяемый вид. Понятно, используя при этом регекспы и прочую автоматизацию, но проверяя каждое изменение глазами. Ну, конкретно с csv мне не приходилось таким заниматься, но вообще бывало. В excel'е, например, когда я будучи молодым дураком, по доброте душевной написал скрипт для автоматизации секретуткам. Скрипт который брал данные из таблички и складывал в другую табличку. Эти тупые женщины, так и не смогли освоить простые правила внесения исходных данных, и довольно долго донимали потом меня, чтобы я своим скриптом сделал бы их работу. (Совсем некстати, но чёт мне вспомнилась весёлая история, с ещё более весёлым обсуждением: https://workplace.stackexchange.com/questions/93696/is-it-un... )
> Комментарии? А как их корректно обрабатывать? Я вот вырезаю нафиг - что
> еще с ними делать, если файл не глазами смотришь?Что с ними делать -- вырезать естественно. Но это дополнительные сложности парсящего кода, которые не включены в регексп.
>> Регекспы используют libpcre или, иногда, какую-нибудь альтернативу. Сколько там строк в
>> libpcre если посчитать с зависимостями?
> ее тестируют, да ;-) Мне вот и интересно, у писателей либ для
> "нормальных языков" есть такая практика, или "у них все работает"?Если тестирование библиотек входит в список необходимых практик для того, что в твоём понимании "нормальный язык", то конечно тестируют. В тех языках в которых я сталкивался с библиотеками для парсинга всяких разных форматов представления данных, типа csv, yaml, toml, и пр, они просто работали. То есть ни разу не было проблем, которые бы порождались кривизной библиотечного кода.
> Ну и я вовсе не призываю пользоваться regex вместо посимвольного конечного автомата
> (конкретно этот вообще для другого был придуман) - я привел его
> просто чтобы в одной строчке сразу показать, что разбор csv -
> на самом деле довольно непростая и не очень-то быстрая процедура. (если
> что, этот пример - конечный автомат, записанный, постфактум, в виде regexp'а
> - хрен иначе такое придумаешь)А... Ну, с данным утверждением сложно не согласиться. Очевидно, я не понял контекста, прежде чем врываться в обсуждение.
там, кстати, дополнительно забавное - наше чудушко кетайское эти терабайтные csv _кусками_ жрет! Пожалуй, на досуге, гляну в код - сам я как-то даже без пол-банки и не соображу, можно ли вообще в взятом с середины csv-файле неведомого характера вообще надежно понять, где у него начало следующей записи.приведенный кусок стандартной библиотеки таким интеллектом не обременен.
>Отлаживать регекспы, с тем чтобы они корректно вели себя на некорректно сформированных данных -- это просто самоубийство.Вот! Зришь в корень! 100500%!!!
Оно судя по всему для хранения бэкапов.
Только таблицы и вью? База данных без логики на серверной стороне? Серьезно? Такое максимум на hello world тянет.
а в redis много логики?Но дело не в этом. вы сейчас совершаете ошибку такую же как вот те товарищи сверху рассуждающие о преимуществе CSV при передаче данных перед всем остальным.
база данных - это не СУБД. а СУБД - это НЕ база данных.
(
CSV файл- в неком смысле- это тоже база данных (такие базы данных называются базами данных на простых файлах). То есть передавая CSV файл - вы по сути передаете "базу данных" в некотором смысле.
)
Логика должна быть на Application Server.
Если вы посмотрите как устроена трехзвенная архитектура, например у Oracle- то обнаружите что логика в базе данных - очень даже хорошо и правильно.
Главным образом, это правильно для Оракла, потому что вся система получается намертво прибитой к нему, а значит денежки продолжат капать.
Трехзвенную архитектуру можно реализовать на любой платформе. Причем тут именно Оракл?
Я привел его просто в качестве примера, как поставщика решений в котором оная хорошо отработана.
>Если вы посмотрите как устроена трехзвенная архитектура, например у Oracle-Ещё к Тому Кайту в бложик asktom сходите поучиться проектировать большие системы :) столько лучей поноса в сторону серверов приложений. Хотя и у самого Оракля есть Weblogic. Ну, просто Томми работает в отделе OracleSQL и у него своя правда. Кривая и косая по меркам остальной планеты.
Если бы ты писал нормальное ПО, то знал бы, что логика на стороне БД зло. Нетестируемое болото, которое никто никогда не разгребет