Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
Сообщение от opennews (??), 07-Мрт-21, 12:25
Проект Dolt развивает СУБД, сочетающую поддержку SQL со средствами версионирования данных в стиле Git. Dolt позволяет клонировать таблицы, создавать форки и выполнять слияния таблиц, а также выполнять операции push и pull по аналогии с действиями в git-репозитории. При этом СУБД поддерживает SQL-запросы и совместима с MySQL на уровне клиентских интерфейсов. Код проекта написан на языке Go и распространяется под лицензией Apache 2.0... Подробнее: https://www.opennet.me/opennews/art.shtml?num=54716
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

2. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+6 +/–
Сообщение от Msk20 (?), 07-Мрт-21, 12:36
Круто. По крайней мере задумка (хотя бы она). Что-то инновационное!
Ответить | Правка | Наверх | Cообщить модератору

	36. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	–2 +/–
	Сообщение от Урри (ok), 07-Мрт-21, 16:01
	Не сказал бы, что это что-то инновационное. Если вам нужна версионность, ее легко реализовать в любой БД просто добавив еще один индекс-столбец "версия" к каждой таблице.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	–4 +/–
	Сообщение от tim2k (ok), 07-Мрт-21, 17:27
	А если приложение не поддерживает  дополнительный столбец? Очень много систем с закрытым кодом, к сожалению, есть на свете.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+4 +/–
	Сообщение от Annoynymous (ok), 07-Мрт-21, 18:40
	Так пусть не поддерживает. Мы ему напишем внешнюю нашлёпку, которая по нашему запросу уже будет откатывать данные на нужное нам состояние. А приложение по-прежнему будет считывать те поля, на которые оно запрограммировано.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+6 +/–
	Сообщение от adolfus (ok), 07-Мрт-21, 20:28
	Значит оно не поддерживает и СУБД Dolt. О чем вообще разговор?
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	108. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (108), 08-Мрт-21, 10:34
	Dolt ~= MySQL на уровне протокола
	Ответить | Правка | Наверх | Cообщить модератору

	110. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от ыы (?), 08-Мрт-21, 11:18
	И где там вон тот "AS OF" ?
	Ответить | Правка | Наверх | Cообщить модератору

	47. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	–2 +/–
	Сообщение от Msk20 (?), 07-Мрт-21, 18:42
	Что-то добавлять. к КАЖДОЙ. А таблиц в БД десятки. Менять много. Так что не так уж и легко.
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	62. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+4 +/–
	Сообщение от ыы (?), 07-Мрт-21, 23:42
	А вы думаете как партицирование делается? Не только на каждую таблицу.. а каждую строку...
	Ответить | Правка | Наверх | Cообщить модератору

	51. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от минона (?), 07-Мрт-21, 20:36
	Нет, не совсем. Подобный подход позволяет версионифицировать данные в одной таблице. Но, как правило, таблиц много, и данные в них связаны. Соответственно, для организации _среза_ данных приходится городить заметно более сложную структуру. Для этого, конечно, новый движок не требуется, достаточно обычного Постгреса. И, конечно, требуется инструмент для конструирования многоэтажных запросов (по опыту, там одних CVE-шек не меньше трех).
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	63. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от ыы (?), 07-Мрт-21, 23:45
	> для организации _среза_ данных мы строим sql  запрос... Зачем перед этим  организовывать физическое присутствие определенных данных? Почему нельзя просто делать это тем же sql запросом? Почему надо для этого запроса каждый раз поднимать базу из бэкапа на какоето число или scn??
	Ответить | Правка | Наверх | Cообщить модератору

	72. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+1 +/–
	Сообщение от минона (?), 08-Мрт-21, 01:00
	Возможно, я не совсем понял вопрос, но в системах, для которых нужно манипулировать данными в стиле Git (см. топик), интересно не просто состояние какой-то одной записи в табличке, а определенного подмножества данных, соответствующих нужному состоянию. Точно так же, вы в Git (а равно как и в SVN и любой другой SCM, не считая RCS и CVS) имеете дело не с отдельным файлом, а с (под)множеством файлов, соответствующих определенному коммиту. То есть, при конструировании запроса вы сначала имеете требуемое состояние (коммит, грубо говоря), а потом под него выгребаете нужные записи с нужными связями. Но опять-таки, связи интересны не абы какие, а только те, которые существовали ровно на момент выбранного коммита. По итогу, типичный запрос в базе для десятка-другого сущностей вполне тянет на половину странички или страничку текста в стандартном редакторе. В подобном запросе присутствуют несколько CTE-шек, ну и вообще, писать и читать такие штуки руками уже становится некомфортно.
	Ответить | Правка | Наверх | Cообщить модератору

	86. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	–1 +/–
	Сообщение от ыы (?), 08-Мрт-21, 09:08
	Это все понятно. И точки зрения академического интереса - можно извернуться... Приведите пример осмысленной задачи решаемой таким образом?
	Ответить | Правка | Наверх | Cообщить модератору

	127. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от B (?), 08-Мрт-21, 23:11
	>> Приведите пример осмысленной задачи решаемой таким образом? а это уже троллинг на уровне детсада.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Ordu (ok), 08-Мрт-21, 04:16
	Эта штука позволяет немного иначе разделить задачи. Это не значит, что в ней можно сделать что-то такое, чего нельзя сделать на голом SQL, но в конце-концов, на C ведь тоже нельзя сделать ничего, чего нельзя было бы сделать на ассемблере -- это не значит что C не нужен, так? Выше написан пример с машинным обучением. У тебя есть куча модификаций нейросетки, которые ты обучаешь на разных данных, и смотришь что получится. Ты можешь код обучения пофиксить, чтобы он принимал аргументом версию бд. Или ты можешь привести бд в состояние, когда она будет выдавать именно те данные, которые сейчас ты хочешь попробовать. При этом, задачивая данные, ты можешь иметь историю этой заточки -- в смысле делать что-нибудь в стиле DELETE что-то-там FROM май-тейбл; а потом dolt commit -m "ёпрст, наш веб-скрапер натащил в базу кучу хлама, он всё портит." Или может dolt commit -m "хмм... а что будет, если эти данные удалить из базы?". Но потом человек занятый веб-скрапом такой: dolt checkout raw-data; INSERT что-то-там INTO май-тейбл; dolt commit -m "наш скрапер ещё данных приволок". Соответственно, когда у тебя через месяц какая-то из нейросеток показала какой-то результат, ты можешь во-первых, попробовать эту нейросетку погонять на разных данных, выбирая их на основе истории -- скажем найти в истории коммит с меседжом "удалить каждую 13 строку, чтобы полоса неудач закончилась", откатить его, и посмотреть что будет. Я очень примитивно занимался обработкой данных, под несоколько психологических экспериментов, но там бывает нужда данные подредактировать (потому что в них, например, есть данные от испытуемого, который не закончив эксперимент сорвался и убежал куда-то, потому что вспомнил о более важных для него делах), может потому, что там нечаянно остались данные с этапа тестирования программы-эксперимента, когда я проходил этот эксперимент десять ряд кряду... Не, я конечно могу в программку, которая считает статистику внести все эти ограничения в SELECT который она делает, но блин это неудобно. Собственно я делал это не поверх sql, а поверх csv, который я положил в git, и рядом с ним программку, которая его обрабатывает. Таким образом я мог иметь историю того и этого рядом.
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	106. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от ыы (?), 08-Мрт-21, 09:59
	прикрутить к git- обертку для запросов на sql?
	Ответить | Правка | Наверх | Cообщить модератору

	107. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от ыы (?), 08-Мрт-21, 10:05
	Хотя это конечно чисто извернуться :) Штука когда есть набор данных которые надо вот так вот кидать туда сюда- называется коллекция. И необходимость привлечения  git для манипуляций с нею -это как раз пример дурно спроектированной системы с чудовищным оверхедом из за непродуманности.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Ordu (ok), 08-Мрт-21, 11:36
	> Хотя это конечно чисто извернуться :) > Штука когда есть набор данных которые надо вот так вот кидать туда > сюда- называется коллекция. И необходимость привлечения  git для манипуляций с > нею -это как раз пример дурно спроектированной системы с чудовищным оверхедом > из за непродуманности. Нет никакой системы, чтобы говорить о проектировании её. Это процесс разработки. Постоянно возникают новые идеи, и 90% из них оказываются пустышкой. Но чтобы понять, что они пустышка, надо попробовать. Это так же как с программированием в незнакомой области. Если ты влезешь, например, в рендеринг векторной графики, не имея особо опыта в этом деле, ты будешь поначалу двигаться наощупь.  Пробовать разные подходы, и отказываться от них. И каждая попытка -- это бранч в git'е, может даже дерево бранчей, из которых ты потом может пару коммитов позаимствуешь, для того, чтобы начать новый бранч для нового подхода. А оверхед не важен. Если ты занят машинным обучением, то этот оверхед ведь будет случаться, когда ты руками что-то там делаешь. Вот ты сейчас готовишь данные для следующего раунда обучения, и какая тебе разница, будут ли твои действия выполняться 0.0001 сек или 0.1 сек? Тут важнее твоё личное удобство. И если тебе удобно для этого использовать git, то почему бы и нет? Не, если этот оверхед будет выливаться в 10 минут перелопачивания данных, то дааа... это перебор. Даже минута много. Хотя, если эта минута нужна одна, на каждый раунд обучения, который длится десять часов, ну и чё? Тут оверхед только с точки зрения эргономики важен.
	Ответить | Правка | Наверх | Cообщить модератору

	139. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (139), 09-Мрт-21, 12:51
	Чем-то напоминает: если вам нужны версии, просто делайте архивы.
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	76. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	–2 +/–
	Сообщение от Аноньимъ (ok), 08-Мрт-21, 01:33
	Да что-то ничего крутого ни в гит ни в "стиле гит" нет. Последние откровенным маразмом попахивает. БД на жаваскрипте надеюсь написана?
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

4. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+4 +/–
Сообщение от Kusb (?), 07-Мрт-21, 12:40
Вроде не такая сложная идея, но прямо историческая крутость.
Ответить | Правка | Наверх | Cообщить модератору

	13. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+5 +/–
	Сообщение от Gogi (??), 07-Мрт-21, 13:59
	Про "крутость" пока неизвестно. Просто сказать "у нас версии данных" мало, нужно знать ЧТО ИМЕННО версионируется, насколько легко это использовать и где это использовать вообще. Ну вот вопросы навскидку: 1. Можно ли версионировать поле отдельной записи? Или это относится только к записи целиком? 2. Каким является атомарный коммит? Все изменения во всех таблицах? Изменения в одной таблице? Изменения конкретной записи? Поля? 3. Можно ли применить отдельно взятый "коммит" к чужеродной СУБД, не перекачивая всю историю изменений? 4. Можно ли из коммита применить достать изменения только конкретной таблицы? 5. Можно ли "схлопнуть" изменения до уровня минимального CRUD? вопросов много и далеко не все однозначны. Подобные "версионники" имеет смысл делать сразу к конкретному применению, потому что иначе вопросы будут неразрешимы.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+4 +/–
	Сообщение от Синдарин (?), 08-Мрт-21, 00:30
	Мы засунули вам абстракцию в абстракцию, чтобы пока вы используете абстракцию, могли получить абстракцию.
	Ответить | Правка | Наверх | Cообщить модератору

9. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	–4 +/–
Сообщение от Онаним (?), 07-Мрт-21, 13:34
Название настораживает. Хотя Go...
Ответить | Правка | Наверх | Cообщить модератору

11. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	–3 +/–
Сообщение от Gogi (??), 07-Мрт-21, 13:52
> версионирования данных в стиле Git Что за чушь?? Причём тут git вообще? Или вы больше не знаете DVCS? Почему не "в стиле Mercurial"? В чём сходство именно с git? Более того - в чём вообще сходство с DVCS? Может, такая СУБД вообще сродни SVN! Аффтар, не бросайся терминами зазря - сначала выясни вопрос. Это обычная "версионная СУБД", хотя с большим количеством вопросов, "как оно работает". В том смысле, будет ли полезна реализация этой версионности в применении уже к реальным приложениям.
Ответить | Правка | Наверх | Cообщить модератору

	22. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+5 +/–
	Сообщение от RNZ (ok), 07-Мрт-21, 14:09
	https://github.com/dolthub/dolt/blob/master/README.md "Dolt is a SQL database that you can fork, clone, branch, merge, push and pull just like a git repository. Connect to Dolt just like any MySQL database to run queries or update the data using SQL commands. Use the command line interface to import CSV files, commit your changes, push them to a remote, or merge your teammate's changes. All the commands you know for Git work exactly the same for Dolt. Git versions files, Dolt versions tables. It's like Git and MySQL had a baby!" Вполне соответствует утверждению "в стиле Git".
	Ответить | Правка | Наверх | Cообщить модератору

	45. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+3 +/–
	Сообщение от Аноним (45), 07-Мрт-21, 18:31
	>It's like Git and MySQL had a baby! Фанфики, которые мы заслужили. А по сабжу - если взлетит, то будет интересно послушать трустори про джунов, которые запушили в мастер или щелнули reset --hard где не надо.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (49), 07-Мрт-21, 20:18
	Зачем нам сын Git x MySQL, если можно внука (Git x Bitcoin) x MongoDB = OrbitDB?
	Ответить | Правка | Наверх | Cообщить модератору

	54. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от YetAnotherOnanym (ok), 07-Мрт-21, 21:39
	Мичурин, залогиньтесь.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+1 +/–
	Сообщение от Аноньимъ (ok), 08-Мрт-21, 01:36
	Откуда берутся все эти уроды?
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	104. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+3 +/–
	Сообщение от ыы (?), 08-Мрт-21, 09:48
	Сон разума рождает чудовищ (с)
	Ответить | Правка | Наверх | Cообщить модератору

	28. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+2 +/–
	Сообщение от имятакое (?), 07-Мрт-21, 14:41
	стул в пепел?)))
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

12. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
Сообщение от Аноним (49), 07-Мрт-21, 13:56
Без биндингов к питону a-la  SQLite (без клиент-серверного говна, чтобы всё было в одном процессе и потоке) - не нужно.
Ответить | Правка | Наверх | Cообщить модератору

	17. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	–2 +/–
	Сообщение от Аноним (17), 07-Мрт-21, 14:05
	Вообще-то игогошечка был сделан для того чтобы твой бидон прихлопнуть нафиг. И собственно в вебне это и происходит везде, особенно в гугеле.
	Ответить | Правка | Наверх | Cообщить модератору

	26. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+1 +/–
	Сообщение от Аноним (49), 07-Мрт-21, 14:21
	Совершенно разные вещи. Одна из главных фич всех скриптовых языков - это REPL. А Go - компилируемый, эффективного REPLа там нет и не будет.
	Ответить | Правка | Наверх | Cообщить модератору

	29. Скрыто модератором	–2 +/–
	Сообщение от Аноним (-), 07-Мрт-21, 14:51
	> Совершенно разные вещи. Одна из главных фич всех скриптовых языков - это > REPL. А Go - компилируемый, эффективного REPLа там нет и не будет. С другой стороны, игогошечка по сравнению с пихоном быстр как понос и для продакшнов это аргумент. И, собственно, в продакшне REPL нафиг не упал. Игрулька для научно-экспериментальных макетчиков, которые не программисты и продакшна не имеют, так что и софт у них под стать оборудованию. Продакшн в вебе - не установка в лабе, через месяц не демонтируют. Так что running costs роялят. А докупать сервера может задолбаться даже гугл.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (32), 07-Мрт-21, 15:04
	>А Go - компилируемый, эффективного REPLа там нет и не будет. Как это связано? Для Haskell есть REPL, хотя он компилируемый по самое небалуй. Даже для C/C++ этот ваш REPL был на базе LLVM.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	40. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	–3 +/–
	Сообщение от Аноним (49), 07-Мрт-21, 16:38
	Я сказал "эффективного". Ты наверное этим REPLом для C++, основанном на устаревшей LLVM (5, когда мой код компилируется Clang 13), не пользовался. Оно и к лучшему, он почти бесполезен, единственный толк от него - когда нужно шаблоны отладить, ибо компилятор такую простыню в сообщениях об ошибках выдаёт (после задержки компиляции), что пожалеешь, что вообще с этими шаблонами и вообще с C++ связался. Repl же отладить шаблоны немного помогает, но крашится часто и память жрёт. Для кода он императивного себя не оправдывает.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (-), 07-Мрт-21, 23:15
	> Я сказал "эффективного". Ну, понимаешь, твоя "эффективность" продакшну очень дорого обходится, сервера бабок стоят. Вот они питонистов и начали уходить. Вплоть до того что вот, крупный продакшн в виде гугла даже свой ЯП расперся сделать. А остальным уже так напрягаться не надо, достаточно програмеров сменить, на игогохе уже изрядо вебманки шпрехает, это не проблема совершенно.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от ыы (?), 08-Мрт-21, 00:13
	Учитывая что серверов у гугла как грязи, и сама архитектура построена на идее дешевого сервера но зато быстро заменяемого - сентенция о проблеме несколько странной выглядит...
	Ответить | Правка | Наверх | Cообщить модератору

	81. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+1 +/–
	Сообщение от Аноним (81), 08-Мрт-21, 03:01
	Сервер может быть дешёвым, но датацентры стоят дорого, особенно когда жрут много энергии и производят тепла. Закон Мура закончился, дальнейшее упрощения труда программистов начинает сказываться на цене обслуживания.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от ыы (?), 08-Мрт-21, 09:21
	Я думаю упрощение труда программиста будет и дальше превалировать над ценой оборудования. а на тепле от датацентров выращивают карпов в обогреваемых прудах...  Но вообще говоря с этого момента разговор без цифр не имеет смысла.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (-), 08-Мрт-21, 09:20
	> Учитывая что серверов у гугла как грязи, и сама архитектура построена на > идее дешевого сервера но зато быстро заменяемого - сентенция о проблеме > несколько странной выглядит... Гонять на том же парке серверов в разы большую нагрузку без докупки "дешевых" серверов - любому капиталисту нравится. Больше профита за те же деньги. Тем более что он один - дешевый. А когда их тысячи, и вопрос в том что датацентров надо в разы больше, это уже вообще совсем не дешево получается. И на этом фоне можно уже и свой ЯП сколхозить, оплатив несколько больших голов и построив вебмакак. Благо, у гугла не будет проблем с наймом новых, если старые заартачатся.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	92. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от ыы (?), 08-Мрт-21, 09:25
	А вы знаете разницу в производительности дешевого сервера и дорогого?  В пересчете на один доллар, евро, мегафлоп или квадратный метр? Ну или хотя бы просто порядок величин представляете?
	Ответить | Правка | Наверх | Cообщить модератору

	128. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от B (?), 08-Мрт-21, 23:17
	мы знаем, а вам  гуглить придется.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	–2 +/–
	Сообщение от Аноним (-), 08-Мрт-21, 23:43
	> А вы знаете разницу в производительности дешевого сервера и дорогого?  В > пересчете на один доллар, евро, мегафлоп или квадратный метр? Ну или > хотя бы просто порядок величин представляете? В пересчете на ватт еще не забудьте. Когда некто оперирует целыми датацентрами, все это уже не пустой звук. И тут дорогим серверам совершенно нечем похвастаться. Оптимальный по энергии режим работы CMOS чипов - вовсе не топовая производительность, что бы там сцаный маркетинг не лечил. Но для этого надо понимать азы этой схемотехники, что сложновато для реднеков.
	Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

	85. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (49), 08-Мрт-21, 08:37
	Это в веб-сервисах. Я же программер на питоне и плюсах программ для десктопа и дейта-саентист. Какие там у Гугла проблемы на хайлоад-серверах, обслуживающих клиентов, меня не очень волнует - мои приложения не обслуживают клиентов и не должны держать тысячи запросов в секунду, главный bottleneck у меня - это диск (потому что я жлоб и SSD брать не буду) и память. Они должны делать свое дело локально.
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	91. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	–1 +/–
	Сообщение от Аноним (-), 08-Мрт-21, 09:22
	> Это в веб-сервисах. Я же программер на питоне и плюсах программ для > десктопа и дейта-саентист. Ага, питон - таки да, для сайентистов с одноразовыми макетами. А для остального он... кхе-кхе. Поэтому гугель и запилил игогошечку. И да, искренне надеюсь что мне никогда не придется иметь дело с вашим софтом.
	Ответить | Правка | Наверх | Cообщить модератору

	59. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (-), 07-Мрт-21, 23:10
	> Совершенно разные вещи. Одна из главных фич всех скриптовых языков - это > REPL. А Go - компилируемый, эффективного REPLа там нет и не будет. В продакшне видите ли скорость приоритетнее. И черт с ним, с REPLом... нахрен он вебне и микросервисам, по большому счету?
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	84. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от CrazyAlex (?), 08-Мрт-21, 07:35
	Да нахрена он вообще? Та же беда, что и с экспериментами в командной строке шелла - замучаешься контролировать состояние окружения. Поэтому я уже много лет всё мало-мальски сложное шелловское сразу пихаю в файлы, а просто командная строка - это для ps | grep какого-нибудь. И точно так же - никакого REPL, только нормальный файл с исходниками и Makefile рядом по возможности, чтобы повторяемо было, и желательно - не только мной
	Ответить | Правка | Наверх | Cообщить модератору

	95. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (-), 08-Мрт-21, 09:28
	> Да нахрена он вообще? Ну вон какой-то дата-саентолог :) вылез. Ему может что-то такое и пригодится. А остальным оно натурально ни в п... ни в красну армию, по большому счету. > много лет всё мало-мальски сложное шелловское сразу пихаю в файлы, а > просто командная строка - это для ps | grep какого-нибудь. Ну да. Поэтому я и понимаю пойнт шелла в таком качестве, но вот нахрен в этом качестве питон для меня загадка. В шелле это какая-то мелкая системная автоматизация по месту. Вызовом сторонних утилсов. > И точно так же - никакого REPL, только нормальный файл с исходниками > и Makefile рядом по возможности, чтобы повторяемо было, и желательно - > не только мной Питонисты антипод этого - чтобы повторить их смертельный номер, придется выискикать вот конкретно вон ту версию пихона. А на полшишечки в сторону и нате вам трейс на три экрана...
	Ответить | Правка | Наверх | Cообщить модератору

	117. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от RNZ (ok), 08-Мрт-21, 14:30
	> Совершенно разные вещи. Одна из главных фич всех скриптовых языков - это > REPL. А Go - компилируемый, эффективного REPLа там нет и не > будет. go run ? Что значит "эффективный REPL"? Вот такой что-ли: https://github.com/motemen/gore/raw/master/doc/screencast.gif
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	34. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Ted (?), 07-Мрт-21, 15:35
	А они есть. https://github.com/dolthub/doltpy
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	39. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	–3 +/–
	Сообщение от Аноним (49), 07-Мрт-21, 16:29
	Он стартует серверный процесс и подключается к нему по сети. Значит будет оверхед на переключение контекста, оверхед на сокет, оверхед на сериализацию, никакого прямого доступа к отображениям в памяти, да ещё и без гарантий завершения сервера, если клиентский процесс упадёт. Поэтому я мультипроцессинг так и не люблю.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (-), 07-Мрт-21, 23:18
	> Он стартует серверный процесс и подключается к нему по сети. Значит будет > оверхед на переключение контекста, оверхед на сокет, оверхед на сериализацию, никакого > прямого доступа к отображениям в памяти Питон сам тормозной как трактор, так что смысла то все это оптимизировать? Чтобы знатно попахать с результатом близким к нулю?
	Ответить | Правка | Наверх | Cообщить модератору

	75. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+1 +/–
	Сообщение от kai3341 (ok), 08-Мрт-21, 01:21
	> Питон сам тормозной как трактор, так что смысла то все это оптимизировать? Чтобы знатно попахать с результатом близким к нулю? Тоже узко. Питон позволяет подключать сишные библиотеки для числодробилок. Если вынести на python логику контроллера (которой овердохера и она часто меняется, но при этом сложной не является), то оверхед будет минимальным (см. профайлер). Если при этом ещё не тупить и использовать asyncio, то процессорное время на python-код будет минимальным Я к чему. Не надо забивать гвозди микроскопом
	Ответить | Правка | Наверх | Cообщить модератору

	96. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (-), 08-Мрт-21, 09:30
	> Тоже узко. Питон позволяет подключать сишные библиотеки для числодробилок. База данных, наверное, не числодробилка? > Я к чему. Не надо забивать гвозди микроскопом Да, и используя базу на го логично и бэк на нем же делать, чтоли. А профайлить питон пусть будет кто-нибудь другой. Сами эти фекалии профайльте.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от kai3341 (ok), 08-Мрт-21, 01:02
	>  Он стартует серверный процесс и подключается к нему по сети. Значит будет оверхед на переключение контекста, оверхед на сокет, оверхед на сериализацию, никакого прямого доступа к отображениям в памяти, да ещё и без гарантий завершения сервера, если клиентский процесс упадёт. Поэтому я мультипроцессинг так и не люблю. Мне даже возразить нечего -- слишком узко мыслите, не поймёте-сс. Что делать, если пользовательский процесс упадёт с сегфолтом посреди транзакции? Как синхронизировать множество подключений? Через временный файл? In-memory кэши хранить в каждом процессе, значит, свои? Как инвалидировать? Или не кэшировать данные вовсе? Тогда что делать с производительностью? Может, не зря индустрия БД запускает в отдельном процессе? Или миллионы опытных программистов ошибаются?
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	78. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноньимъ (ok), 08-Мрт-21, 01:50
	Смузихлебы способны и не на такое. Это вы тут узко мыслите! Нужно все разделить на микросервисы с персональными кешами и кеширующими микросервисами. И тогда взлетит!
	Ответить | Правка | Наверх | Cообщить модератору

	80. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от kai3341 (ok), 08-Мрт-21, 02:00
	> Смузихлебы способны и не на такое. Это вы тут узко мыслите! > Нужно все разделить на микросервисы с персональными кешами и кеширующими микросервисами. И тогда взлетит! К -- Конструктивность. Сразу видно -- Инженерище! /thread
	Ответить | Правка | Наверх | Cообщить модератору

	87. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (49), 08-Мрт-21, 09:16
	>Что делать, если пользовательский процесс упадёт с сегфолтом посреди транзакции? Перезапустить. >Как синхронизировать множество подключений? Через временный файл? Многопроцессность не нужна, у нас bottleneck при импорте - случайное чтение и запись. Клиент один и только один. Если остальные клиенты подключаются во время импорта - значит их проблемы. >In-memory кэши хранить в каждом процессе, значит, свои? Как инвалидировать? Или не кэшировать данные вовсе? Тогда что делать с производительностью? Да, свои, но у нас только один процесс. Вопрос только в том, зачем вообще хранить свои кеши, если кеширование - это забота ОС, а забота разраба базы данных - иметь отображение на часть файла, которую надо кешировать? >Может, не зря индустрия БД запускает в отдельном процессе? Или миллионы опытных программистов ошибаются? У них другие задачи. Эта же база изначально позиционируется как база для хранения datasetов и заливки их на их dolthub. Для хранения datasetов нужна не сетевая база, а встраиваемая, можно вообще не базу, а HDF-файл.
	Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

	126. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от kai3341 (ok), 08-Мрт-21, 22:13
	> Перезапустить Отлично. Опыта работы с БД у вас нет -- иначе вы бы знали, что такой фокус закончится повреждением структуры БД. Её кто-то должен восстановить. Или нет? Когда это должно произойти? Поехали дальше. Кто её должен перезапустить? Сколько раз? > Многопроцессность не нужна, у нас bottleneck при импорте - случайное чтение и запись. Клиент один и только один. Если остальные клиенты подключаются во время импорта - значит их проблемы. То есть тот факт, что вы в своём маня-мирке не видите смысла и возможности подключения нескольких клиентов к одной БД -- это проблемы БД > bottleneck при импорте - случайное чтение и запись Расскажу страшную тайну. Предметная область в первую очередь определяет сценарий работы с БД. В каких-то таблицах это случайный доступ, другие работают в режиме append-only, третьи работают в режиме "меняются только последние записи", а в четвёртых часто происходит rollback. И это только верхушка айсберга. Это я к чему -- bottleneck может быть где угодно. Узко мыслите, слишком узко > Да, свои, но у нас только один процесс У *тебя* один процесс. Кто-то процессит сотни гигабайт данных, например, по астрономии -- там необходимо процессить параллельно. Если у тебя данных мало, раз хватает одной машины, это не значит, что у всех остальных данных тоже мало. Или ты думал, БД разрабатывается исключительно под твои нужды? > если кеширование - это забота ОС Оказывается, redis, memcached, ElasticCache не нужны -- это всё должна разруливать ОС. Пацаны то и не знали. Может, расскажешь, как ОС должна решать эти проблемы? ОС за тебя должна догадываться, что одни данные надо закэшировать, а другие нет? По какому алгоритму? PS: io-кэш никто не отменял. Только вот расскажи, как ОС должна обрабатывать ситуацию, когда в фоне у тебя данные процессятся (то есть происходит постоянное чтение входных данных и запись выходных), в фоне же торрент качает и раздаёт, а сам ты интернеты сёрфишь (а браузер тоже кэширует кучу всего). Что должно оказаться в кэше? > Для хранения datasetов нужна не сетевая база, а встраиваемая, можно вообще не базу, а HDF-файл. Я чуть выше говорил, что это только твой кейс. Из этого не следует, что других кейсов не существует. Будь то астрономия или биоинформатика -- там огромные объёмы данных, которые отпроцессить надо за конечное время, и мультипроцессинг и множество нод -- жизненная необходимость
	Ответить | Правка | Наверх | Cообщить модератору

	146. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (146), 10-Мрт-21, 10:01
	>Отлично. Опыта работы с БД у вас нет -- иначе вы бы знали, что такой фокус закончится повреждением структуры БД. Её кто-то должен восстановить. Или нет? Когда это должно произойти? Это только если отключён журнал. Отключение журнала повысит производительность, но ненамного. Прирост не стоит риска. >Её кто-то должен восстановить. Или нет? Когда это должно произойти? Она сама, при перезапуске. Повреждение будет только если файлы журналов стереть. >То есть тот факт, что вы в своём маня-мирке не видите смысла и возможности подключения нескольких клиентов к одной БД -- это проблемы БД Подключение нескольких клиентов к SQLite есть. Но я его не использую, вместо этого врубаю монопольный доступ на запись. >Оказывается, redis, memcached, ElasticCache не нужны -- это всё должна разруливать ОС. Пацаны то и не знали. Может, расскажешь, как ОС должна решать эти проблемы? ОС за тебя должна догадываться, что одни данные надо закэшировать, а другие нет? По какому алгоритму? По тому же, по которому она свопит. >Только вот расскажи, как ОС должна обрабатывать ситуацию, когда в фоне у тебя данные процессятся (то есть происходит постоянное чтение входных данных и запись выходных), в фоне же торрент качает и раздаёт, а сам ты интернеты сёрфишь (а браузер тоже кэширует кучу всего). Что должно оказаться в кэше? А никак, когда у меня данные обрабатываются, я почти всю свободную память на машине отдаю базе под отображения. Вот эти отображения и есть кеш, который управляется ОС через менеждер памяти. >Это я к чему -- bottleneck может быть где угодно. Узко мыслите, слишком узко >У *тебя* один процесс. >Я чуть выше говорил, что это только твой кейс. Из этого не следует, что других кейсов не существует. Аргументы приняты. Я тут в основном свой случай и обсуждаю. Просто для меня возня с процессами не стоит выигрыша. В плюсовом импортере попробую поспавнить потоки.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от kai3341 (ok), 11-Мрт-21, 15:03
	> Это только если отключён журнал. Отключение журнала повысит производительность, но ненамного. Прирост не стоит риска. Это забавный тонкий момент. Журнал как раз позволяет восстановить структуру в автоматическом режиме. От повреждения данных журнал не защищает. А вопрос был про восстановление. Классика -- рестарт сервиса после аварии. Не менее классика -- стартует одновременно более 10 инстансов процесса -- производительности всегда мало. Далее они одновременно обнаруживают, что БД повреждена и как-то должны договориться, кто из них восстанавливает её из журнала. Вот в этом самом момента важно не воспроизвести мемас про девушку и негров. Тут возможно много yблюдских и не очень решений. Вот я и спрашивал -- какое из yблюдских и не очень решений применить здесь? Видимо, оно же будет применяться и для синхронизации транзакций при штатной работе БД. И ещё раз повторю вопрос: какое решение нужно применить для синхронизации разных рабочих процессов? > Она сама, при перезапуске. Повреждение будет только если файлы журналов стереть. О, тут ещё есть интересный грабледром. Попробуй штатно остановить постгрю и стереть её журналы -- повреждения и не будет, да? PS: не делай этого. > По тому же, по которому она свопит. Идея почти гуд. Объяснишь, зачем тогда добавлялись флаги O_DIRECT, O_DSYNC, O_RSYNC и O_SYNC? Почему они активно используются серверами БД?
	Ответить | Правка | Наверх | Cообщить модератору

	97. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+1 +/–
	Сообщение от Аноним (-), 08-Мрт-21, 09:32
	> Что делать, если пользовательский процесс упадёт с сегфолтом посреди транзакции? Актуальная проблема для питонистов, только обычно падает с трехэтажным стектрейсом сам кусок питона, потому что при его кодинге гнали как на пожар и на всякие там отклонения от идеаа клали болт. А если там сеть упала, памяти не хватило или там что еще - УПС. И в свете этого - ну не питонистам с их "обработкой ошибок" такими мелочами париться вообще. Понимаю если б сишники какие так зудели еще.
	Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

	125. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	–1 +/–
	Сообщение от kai3341 (ok), 08-Мрт-21, 21:18
	> Актуальная проблема для питонистов, только обычно падает с трехэтажным стектрейсом сам кусок питона, потому что при его кодинге гнали как на пожар и на всякие там отклонения от идеаа клали болт. А если там сеть упала, памяти не хватило или там что еще - УПС. Оказывается, проблема питона в стэктрейсах. Вы их боитесь? Они вас обидели? > И в свете этого - ну не питонистам с их "обработкой ошибок" такими мелочами париться вообще. Понимаю если б сишники какие так зудели еще. Ярлыки.
	Ответить | Правка | Наверх | Cообщить модератору

	130. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+1 +/–
	Сообщение от Аноним (-), 08-Мрт-21, 23:47
	> Оказывается, проблема питона в стэктрейсах. Вы их боитесь? Они вас обидели? Когда все резко и внезапно обламывается с адским стэктрейсом - это неприятно, да. И таки было достаточно неприятного опыта такого плана. > Ярлыки. Статистические наблюдения.
	Ответить | Правка | Наверх | Cообщить модератору

14. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
Сообщение от Аноним (17), 07-Мрт-21, 14:03
А чего тогда не Golt? :P
Ответить | Правка | Наверх | Cообщить модератору

	133. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от B (?), 09-Мрт-21, 00:44
	go it != do it
	Ответить | Правка | Наверх | Cообщить модератору

15. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	–2 +/–
Сообщение от Gogi (??), 07-Мрт-21, 14:04
Сейчас чуть дотошнее прочёл и прям взрыв мозга: Клонировать таблицы? Ну, допустим! И ЧТО ДАЛЬШЕ? Как писать запрос? SELECT * FROM T(версия 1) LEFT JOIN T2(версия 17) так шт0ле?? А если в оригинальную таблицу внесли данные, а в клоне вообще добавили NON-NULL поле - как делать merge? Ведь non-null надо чем-то заполнять! (и молись, если это не FK!) Короче, есть серьёзное подозрение, что "версионирование" там настолько убогое, что хватит максимум на "снэпшот" состояния в один момент времени - ну так это и обычный backup делает!
Ответить | Правка | Наверх | Cообщить модератору

	42. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (42), 07-Мрт-21, 17:14
	Вот тоже интересно что-нибудь серьезней обычного bcp они сделали....
	Ответить | Правка | Наверх | Cообщить модератору

	55. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	–1 +/–
	Сообщение от YetAnotherOnanym (ok), 07-Мрт-21, 21:46
	Если идеи, заложенные в эту СУБД, настолько ортогональны всему, что ты когда-то усвоил - скорее всего, это просто не твоё. Не насилуй себя, пройди мимо.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	57. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+1 +/–
	Сообщение от ыы (?), 07-Мрт-21, 22:44
	Скажите пожалуйста, а зачем версионировать таблицы БД "со статистикой о коронавирусе"? Мне казалось что версионировать надо данные а не таблицы... Кроме службы безопасности кому это надо? А для службы безопасности есть такая штука как аудит... Например есть отчет о состоянии ковид на 1 января... и есть такой же отчет за 5 января. Это разные версии отчета, которые хранятся в виде связанных записей в одной и той же таблице и извлекаются по признаку даты отчета. Зачем нужна версия самой таблицы? То есть традиционным способом, мы, чтобы получить отчет за 1 января- должны будем восстановить базу из бэкапа за 2 число? Вместо того чтобы просто сделать выборку по данным по признаку? В чем смысл?
	Ответить | Правка | Наверх | Cообщить модератору

	64. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (42), 07-Мрт-21, 23:55
	Это похоже попытка сделать темпоральную БД. Компании разные пыжились но как я погляжу это не взлетело.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+1 +/–
	Сообщение от ыы (?), 08-Мрт-21, 00:07
	InfluxDB называется... Вон работает как лошадь - метрики мониторинга пишет..
	Ответить | Правка | Наверх | Cообщить модератору

	74. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (42), 08-Мрт-21, 01:19
	Больше имело в виду полностью скуль база. На которой можно делать всё тоже самое, но ещё и выбирать в какой момент времени делать запрос. Инфлюкс с этим как-то не очень.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от ыы (?), 08-Мрт-21, 09:28
	>выбирать в какой момент времени делать запрос зачем?
	Ответить | Правка | Наверх | Cообщить модератору

	113. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (42), 08-Мрт-21, 11:39
	Затем же зачем и всё остальное - упростить работу. Всё в одной таблице а заморачиваться дополнительными полями мне не надо. Сейчас есть одно ПО что текущие данные хранит в одних таблицах а потом уносит данные в исторические таблицы. И мне надо в запросах все таблички менять, если надо получить что было раньше. Ещё оно архивирует данные с некоторой периодичностью. Если в промежутке были изменения они не попадут в историческую таблицу. А тут все батарейки в комплекте.
	Ответить | Правка | Наверх | Cообщить модератору

	71. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+1 +/–
	Сообщение от YetAnotherOnanym (ok), 08-Мрт-21, 00:44
	А почему нельзя при изменении одной ячейки считать всю таблицу со старым значением одной версией, а с новым значением - другой? Где-нибудь сказано, что при этом должны физически клонироваться на диске все оставшиеся неизменными ячейки? > для службы безопасности есть такая штука как аудит Ну дык вот для него же, например. > есть отчет о состоянии ковид на 1 января... и есть такой же отчет за 5 января А потом в отчёте за 5 января вдруг оказываются некие более другие цифры. СМИ истерят, биржи лихорадит, некие люди делают огромные деньги, потому что ждали этих новостей, а потом админ не только одной-единственной командой восстанавливает правильное значение статистики за 5 января, но и столь же быстро выдаёт полный отчёт для ФБР и Комиссии по ценным бумагам с указанием всех подробностей о внесении искажённых данных в БД. Или представь себе ситуацию, когда ты приходишь домой, а там чужие люди суют тебе в нос свежую выписку из ЕГРП и предлагают собрать манатки и валить по-хорошему.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	98. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от ыы (?), 08-Мрт-21, 09:33
	Это все элементарно делается уже имеющимися технологиями.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+1 +/–
	Сообщение от YetAnotherOnanym (ok), 08-Мрт-21, 14:30
	Доски тоже можно прикреплять деревянными штырьками, забивая их булыжником. Но гвозди и молоток лучше.
	Ответить | Правка | Наверх | Cообщить модератору

	143. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (-), 09-Мрт-21, 16:25
	> Но гвозди и молоток лучше. Именно так, всякие dolt и прочие булыжники не нужны.
	Ответить | Правка | Наверх | Cообщить модератору

18. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+3 +/–
Сообщение от Аноним (18), 07-Мрт-21, 14:05
Интересно, что у БД есть история с 2016 года. И до 2018 года ей занимались абсолютно другие люди https://github.com/dolthub/dolt/graphs/contributors, которые сейчас не состоят в команде https://www.dolthub.com/team А текущая команда появилась в конце 2018 и продолжила работу над уже существующим проектом и судя по всему тогда и появился бренд DoltDB (2018-11-30 дата регистрации домена).
Ответить | Правка | Наверх | Cообщить модератору

35. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	–5 +/–
Сообщение от Иваня (?), 07-Мрт-21, 15:45
О, что-то интересное, да ещё и на Golang. Спасибо большое!
Ответить | Правка | Наверх | Cообщить модератору

41. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	–1 +/–
Сообщение от DIO (?), 07-Мрт-21, 16:42
с одной стороны инт. , а с другой стороны "аназачем"? ну вот реально а на зачем?! ради интереса или профита то да но вот где это использовать и реальное практическое применение какое? при разработке софта есть миграции и откаты и т.д. работает (касательно структуры), касательно данных никто бекапы не отменял. Смешение технологий конечно оригинально но сильно непонятен смысл т.е. с какой проблемой столкнулись что натолкнуло на создание сего , чего не хватало. т.е. вариантов аналогичного решения типа SQL + что-то (тут варианты в зависимости от задачи и нужного результата) есть. Всунутое в один стакан навевает на большую нестабильность системы в целом. Пожуем увидим...
Ответить | Правка | Наверх | Cообщить модератору

	48. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Kusb (?), 07-Мрт-21, 19:49
	Распределённый Интернет, не нужно быть постоянно связанным всеми со всем миром.
	Ответить | Правка | Наверх | Cообщить модератору

52. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+2 +/–
Сообщение от anonimous (?), 07-Мрт-21, 20:37
dictionary.cambridge.org › dictionary › english › dolt dolt definition: 1. a stupid person 2. a stupid person.
Ответить | Правка | Наверх | Cообщить модератору

	79. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноньимъ (ok), 08-Мрт-21, 01:56
	Я понял, это шутку к 1му апреля готовят.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (-), 08-Мрт-21, 23:48
	> Я понял, это шутку к 1му апреля готовят. Не, ну а чего? Разработчики честны относительно аудитории. У го и на логотипе, видите ли, хомячок.
	Ответить | Правка | Наверх | Cообщить модератору

53. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+2 +/–
Сообщение от Аноним (53), 07-Мрт-21, 21:26
Here we go again
Ответить | Правка | Наверх | Cообщить модератору

56. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
Сообщение от Аноним (56), 07-Мрт-21, 22:24
Сначала я подумал "о, круто, какая свежая идея", а потом подумал ещё и понял, что фигня. И вот почему. Откат в любой базе данных подразумевает откат на некое консистентное состояние, в котором бизнес (именно бизнес!) транзакции завершены и подтверждены. Ну там платежка например ушла в банк и есть подтверждение, что она принята в работу. Или платежка точно не ушла и не уйдёт автоматически, если случится откат на предыдущий бэкап. Чтобы решить эту задачу, не нужно городить никаких (псевдо) гитов, это делается логикой самого приложения.
Ответить | Правка | Наверх | Cообщить модератору

	58. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+1 +/–
	Сообщение от ыы (?), 07-Мрт-21, 22:54
	Мне вот тоже непонятно  чем выборка по актуальному признаку при физическом отсутствии лишних данных (состояние базы в некий момент времени) лучше выборки тем же данным при наличии еще других данных в таблице? Ну кроме размера области поиска конечно :)
	Ответить | Правка | Наверх | Cообщить модератору

	93. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Crazy Alex (ok), 08-Мрт-21, 09:26
	Допустим, у вас датасет плюс-минус один, но может пополняться. А состояний, в которых он используется - много, и часть из них можно обновить, часть - нет. В приложении это реализовать можно, но здесь это уже сделали за вас, ещё и внешние инстурменты управления дали. Для всяких исследований со статистикой мне это сходу нравится, выше про датасеты для нейронок вон упоминали... вот что-то подобное.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от ыы (?), 08-Мрт-21, 09:35
	> А состояний, ... - много, Это просто дурно спроектированная база данных и ветер в консерватории программиста написавшего систему.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Ordu (ok), 08-Мрт-21, 03:53
	> Сначала я подумал "о, круто, какая свежая идея", а потом подумал ещё и понял, что фигня. И вот почему. Угу, и git не нужен, потому что бизнесу он бесполезен.
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	100. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+1 +/–
	Сообщение от Аноним (-), 08-Мрт-21, 09:35
	> Угу, и git не нужен, потому что бизнесу он бесполезен. После того как я увидел ТОПА ТРАНСНАЦИОНАЛЬНОЙ КОРПОРАЦИИ сцуко регающегося на гитхабе с аргументом "там тусуется много кастомеров и они используют это!" - я в этом почему-то совсем не уверен.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (56), 08-Мрт-21, 16:29
	Это вы уж сами придумали. Тут проблема не в конкретном гите, а в том, что будет в базе при манипуляциях в таблицах. Как мне видится, обсуждаемая идея имеет смысл в очень узкой области применений, а именно, если таблицы друг с другом не связаны и их можно модифицировать независимо друг от друга. Примеры коллеги привели. В статистику поиграть допустим, уберем данные такие-то, потом другие. Ну да, удобно сохранять состояние при таких экспериментах. А если (я всё про платежи) некое сообщение фигурирует в 20 таблицах (ну там история модификаций, передача по документообороту, уведомления всякие, взаимодействие с внешними приложениями), то как тут форкать и мержить отдельные записи в таблицах? Я, хоть дерись, не понимаю, как обеспечить консистентность данных в таком случае. Тут только откат помогает и ручная выверка.
	Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

	121. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Ordu (ok), 08-Мрт-21, 17:11
	> Как мне видится, обсуждаемая идея имеет смысл в очень узкой области применений, а именно, если таблицы друг с другом не связаны и их можно модифицировать независимо друг от друга. Примеры коллеги привели. В статистику поиграть допустим, уберем данные такие-то, потом другие. Ну да, удобно сохранять состояние при таких экспериментах. "Узкой" области применений?! Data science растёт как на дрожжах, и я бы не назвал её узкой областью. Уже, конечно, чем бухгалтерия, но не узкая. Впрочем, даже если и узкая область, и что с того? Узкие области не заслуживают того, чтобы иметь собственные инструменты, и пускай они пользуются инструментами для них слабо пригодными, и как хотят так и выкручиваются? Да и вообще, sqlite очень удобен иногда вместо файлов на диске, и не из-за того, что он relational, а просто как способ быстро искать данные в каком-то датасете. Можно придумать свой формат хранения, хранить там в десятках (сотнях/тысячах/...) файлов, или в один файл упаковать, но с этим возни много. А sqlite позволяет свалить всё в кучу, и потом оттуда выуживать то, что надо, причём с таким удобным синтаксисом для выборки, который в редком языке программирования можно найти. Мне разве что R в голове приходит как пример языка, который может поконкурировать с SQL в плане удобства создания выборки данных. Но в R, прежде чем работать с данными, их надо сначала загрузить с диска, а загружать их откуда? Из гигантского csv? Или может из SQL базы? > А если (я всё про платежи) некое сообщение фигурирует в 20 таблицах > (ну там история модификаций, передача по документообороту, уведомления всякие, взаимодействие > с внешними приложениями), то как тут форкать и мержить отдельные записи > в таблицах? Я, хоть дерись, не понимаю, как обеспечить консистентность данных > в таком случае. Тут только откат помогает и ручная выверка. В новости предложен список возможных применений этому dolt: "в DoltHub можно найти различные БД со статистикой о коронавирусе, коллекциями аннотированных данных для систем машинного обучения, языковыми лексическими базами, коллекциями изображений, наборами для классификации объектов и информацией о принадлежности IP-адресов". То есть, как я понимаю, даже не возможных, а реальных применений. Здесь нет ни слова про бухгалтерию. И при этом, да, я не очень понимаю проблемы. С форком вообще я не вижу никаких проблем даже потенциально, сколько бы там таблиц не было. А с мергом... Какие там могут быть проблемы? Ну, кроме тех, которые возникают и при мерге текстовых файлов?
	Ответить | Правка | Наверх | Cообщить модератору

	134. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (56), 09-Мрт-21, 01:26
	> С форком вообще я не вижу никаких проблем даже потенциально Сообщение набрано и отправлено, квиток от внешней системы ещё не получен, и тут, опачки, форк. Квиток приходит в другую ветку. Восстановили предыдущее состояния, а там квитка нет, и сообщение уехало второй раз. А на той стороне муфлоны его провели дважды, и списали, например вместо двух миллионов денег четыре. Ахрененно. Я ж говорю, всё это хорошая вещь, но для специфических применений. Ну вот накидали в базу картинок и вертим туда сюда. Испортить довольно сложно, когда это вещь в себе. Но чтоит подвязать внешние взаимодействия...
	Ответить | Правка | Наверх | Cообщить модератору

	136. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Ordu (ok), 09-Мрт-21, 04:07
	>> С форком вообще я не вижу никаких проблем даже потенциально > Сообщение набрано и отправлено, квиток от внешней системы ещё не получен, и > тут, опачки, форк. Квиток приходит в другую ветку. Восстановили предыдущее состояния, > а там квитка нет, и сообщение уехало второй раз. А на > той стороне муфлоны его провели дважды, и списали, например вместо двух > миллионов денег четыре. Ахрененно. То же самое будет и с сорцами в git, ежели ты, проводя серию связанных изменений, форкнешь сорцы посередине серии, и продолжишь серию в одной из веток. В другой будут скорее всего некомпилируемые сорцы. Это фича, а не баг.
	Ответить | Правка | Наверх | Cообщить модератору

	137. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	–1 +/–
	Сообщение от Аноним (56), 09-Мрт-21, 09:06
	От форков сорцов в гит ни горячо, ни холодно, потому что это никак не влияет на реальность.
	Ответить | Правка | Наверх | Cообщить модератору

	138. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Ordu (ok), 09-Мрт-21, 09:15
	> От форков сорцов в гит ни горячо, ни холодно, потому что это > никак не влияет на реальность. Ты про реальность, с точки зрения бизнеса? Когда программист потратил рабочий день, на то, чтобы понять почему оно не компилируется -- это вообще-то денег стоит.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (56), 09-Мрт-21, 17:30
	От того, что у программиста не компилируется, реальности пофигу.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Ordu (ok), 10-Мрт-21, 00:03
	> От того, что у программиста не компилируется, реальности пофигу. От того, что проводки не проводятся реальности тоже пофигу.
	Ответить | Правка | Наверх | Cообщить модератору

	147. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (56), 11-Мрт-21, 09:04
	Да-да, интересно, как будет брызгать слюною конкретный Ordu, когда его платежи (или ему платежи, например зарплата) где-то потеряются. Ну там форкнули, туда сюда не та ветка, мы разбираемся, приходите через месяц. Или два.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Ordu (ok), 11-Мрт-21, 11:03
	Всегда меня озадачивало, как люди могут жить в своём информационном пузырьке и не представлять себе, что бывает что-то снаружи его.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Crazy Alex (ok), 08-Мрт-21, 09:21
	Речь не об однократном откате, а о том, что для разных ситуаций "правильное" (консистентное, конечно) состояние - разное. Зачем это надо - вопрос другой, но особого криминала не вижу - допустим, проводим какие-то статистические исследования или там психологию - батареи тестов, тупящие респонденты, что-то не вовремя данные получили, одна анкетка в один результат считается, дгугая - в три, и так далее. Иметь возможность форкать и мержить датасеты в этом плане было бы удобно, и действительно ровно так же, как и исходники под гитом, и с теми же плюшками - всё в принципе хранится в одном месте, но нормально аннотировано и есть инструменты для работы со всем деревом форков. Так-то и исходники можно в куче каталогов хранить и ручками или скриптами копировать - но неудобно. Вот идея в том, чтобы эту логику (видать относительно чатсо используемую в каких-то контекстах)  вытащить вовне, а не делать каждый раз в приложении. А заодно - дать возможность нормально это администрировать извне - приложение может вообще не знать, что там за форки (благо, оно ещё и mysql-совместимое).
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	103. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+1 +/–
	Сообщение от ыы (?), 08-Мрт-21, 09:38
	> особого криминала не вижу > проводим какие-то статистические исследования или там психологию - батареи тестов, тупящие респонденты, При исследовании -  подмена данных ради хорошего результата- это все таки криминал :)
	Ответить | Правка | Наверх | Cообщить модератору

	112. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Ordu (ok), 08-Мрт-21, 11:39
	Без этой подмены ничего не работает. В сыром датасете всегда куча мусора. И его надо вычищать. Другое дело, что, если по-хорошему, это всё должно документироваться и описываться, чтобы читающие результаты исследования могли бы сами судить, насколько эта чистка повлияла на результат.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Аноним (-), 08-Мрт-21, 23:52
	> Без этой подмены ничего не работает. В сыром датасете всегда куча мусора. "Если факты не подтверждают теорию, от них нужно избавиться!" (cледствие из законов мерфи)
	Ответить | Правка | Наверх | Cообщить модератору

	124. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от CrazyAlex (?), 08-Мрт-21, 19:53
	Во-первых, всегда есть первичная обработка - выкинуть сильные выбросы, явный мусор в ответах и подобное. Во-вторых речь не о подгонке, а о том, что ты, допустим, собрал какой-то набор, стал обрабатывать, отдал кому-то результаты на посмотреть, тут тебе тормоза анкеты приволокли, ты их в датасет добавил - хочется иметь удобные средства переключения между тем, что уже обработано и обновлённым набором. Потом следующая пачка пачка пришла - ты их добавил в базу, смержил - и легко переключаешься между отдельными наборами и общим. И так далее. В общем, простота манипуляций - это хорошо.
	Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

65. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
Сообщение от Аноним (65), 08-Мрт-21, 00:01
Идея интересная, но чем в данном случае будет merge. OK, допустим это слияние двух изменений в какое-то третье изменение включающее оба. На графе всё норм, но как будет выполняться хотя бы простейшее из них. Например, с текстом всё более или менее ясно - строи упорядочены и привязаны к контексту предыдущих и последующих строк. В таблицах в общем случае порядка нет и строки в общем случае не связаны между собой. Как можно тут смержить автоматом даже две вставки. Тут либо придётся вводить обязательные кластеризованные первичные ключи, которые к тому же возможно не должны быть строго суррогатными. Это немного ломает красоту исходной идеи. А без слияний с достаточным уровнем автоматики всё это мало что даёт. Хотя возможно в рамках разработки появится какой-то новый инструмент для слияний структурированных данных, даже если в целом сама БД совсем не взлетит.
Ответить | Правка | Наверх | Cообщить модератору

67. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
Сообщение от ыы (?), 08-Мрт-21, 00:11
Мне кажется, что база данных, в которой определенный scn или момент времени имеет значение большее чем точка отката на бэкап - это дурно спроектированная база данных.
Ответить | Правка | Наверх | Cообщить модератору

	99. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от Crazy Alex (ok), 08-Мрт-21, 09:33
	Это если вы там бахгалтерию или регистрантов на сайте храните. А для исследований разных - отличная идея. Для навороченных многоголовых коллекций (фотографии те же) - то же - то, что доктор прописал. Ну там - взял в базе фото теги для конкретной съёмки, добавил другие, пару-тройку выкинул и назвал это "выставка Х" - и у тебя осталась последовательность того, что делал чтобы этот наборчик получить. А потом когда захотел сделать "лучшее с выставок" - можешь проследить когда и как ты на эти выставки работы отбирал.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от ыы (?), 08-Мрт-21, 09:36
	По моему это придумывание задач под забавную игрушку попавшую в руки...
	Ответить | Правка | Наверх | Cообщить модератору

69. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+2 +/–
Сообщение от ыы (?), 08-Мрт-21, 00:16
>При этом Dolt скорее является инструментом для манипулирования данными, чем системой обработки запросов У приличных баз данных есть такая штука как флэшбек... И от шо я скажу- если вам часто надо делать флэшбек- вы чтото в принципе делаете неправильно...
Ответить | Правка | Наверх | Cообщить модератору

105. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
Сообщение от ыы (?), 08-Мрт-21, 09:50
Кстати, а почему они не написали с точностью до наоборот - прикрутить к git- обертку для запросов на sql?
Ответить | Правка | Наверх | Cообщить модератору

	109. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
	Сообщение от ыы (?), 08-Мрт-21, 10:49
	Да именно так: берем обычный немодифицированный git (любой) берем обычный немодифицированный postgresql (mssql, oracle) берем драйвер к git и линкуем нашу базу на postgresql к сырым данным на git. вот собственно и все... обычная связка для интеграции. Если очень хочется...
	Ответить | Правка | Наверх | Cообщить модератору

114. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+1 +/–
Сообщение от Прохожий (??), 08-Мрт-21, 12:54
Написано на Go. Как это чудо будет вести себя под высокими нагрузками с большим количеством пользователей, интересно. Там же GC всё тормозить будет нещадно, как это случилось у дискорда, например. И ещё. Как уже заметили, у приличных СУБД есть flashback - та же версионность по большому счёту. Так в чём, собственно, новшество?
Ответить | Правка | Наверх | Cообщить модератору

118. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
Сообщение от msgod (ok), 08-Мрт-21, 14:49
Почему не на блохчлене? Даешь гит овер блохчлен субд.
Ответить | Правка | Наверх | Cообщить модератору

119. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
Сообщение от Аноним (119), 08-Мрт-21, 15:43
Манипулировать данными... это всегда хорошо.
Ответить | Правка | Наверх | Cообщить модератору

122. "СУБД Dolt, позволяющая манипулировать данными в стиле Git"	+/–
Сообщение от Аноним (122), 08-Мрт-21, 18:47
Я помню, что хотел такую штуку написать, но уже не помню зачем.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема