forum.opennet.ru - "СУБД Dolt, позволяющая манипулировать данными в стиле Git" (122)

"СУБД Dolt, позволяющая манипулировать данными в стиле Git"

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

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

Оглавление

Круто По крайней мере задумка хотя бы она Что-то инновационное , Msk20 (?), 12:36 , 07-Мрт-21, (2) +6

Не сказал бы, что это что-то инновационное Если вам нужна версионность, ее легк, Урри (ok), 16:01 , 07-Мрт-21, (36) –2

А если приложение не поддерживает дополнительный столбец Очень много систем с , tim2k (ok), 17:27 , 07-Мрт-21, (43) –4

Так пусть не поддерживает Мы ему напишем внешнюю нашлёпку, которая по нашему за, Annoynymous (ok), 18:40 , 07-Мрт-21, (46) +4
Значит оно не поддерживает и СУБД Dolt О чем вообще разговор , adolfus (ok), 20:28 , 07-Мрт-21, (50) +6

Dolt MySQL на уровне протокола, Аноним (108), 10:34 , 08-Мрт-21, (108)

И где там вон тот AS OF , ыы (?), 11:18 , 08-Мрт-21, (110)

Что-то добавлять к КАЖДОЙ А таблиц в БД десятки Менять много Так что не так , Msk20 (?), 18:42 , 07-Мрт-21, (47) –2

А вы думаете как партицирование делается Не только на каждую таблицу а каждую, ыы (?), 23:42 , 07-Мрт-21, (62) +4

Нет, не совсем Подобный подход позволяет версионифицировать данные в одной табл, минона (?), 20:36 , 07-Мрт-21, (51)

мы строим sql запрос Зачем перед этим организовывать физическое присутствие, ыы (?), 23:45 , 07-Мрт-21, (63)

Возможно, я не совсем понял вопрос, но в системах, для которых нужно манипулиров, минона (?), 01:00 , 08-Мрт-21, (72) +1

Это все понятно И точки зрения академического интереса - можно извернуться П, ыы (?), 09:08 , 08-Мрт-21, (86) –1

а это уже троллинг на уровне детсада , B (?), 23:11 , 08-Мрт-21, (127)

Эта штука позволяет немного иначе разделить задачи Это не значит, что в ней мож, Ordu (ok), 04:16 , 08-Мрт-21, (83)

прикрутить к git- обертку для запросов на sql , ыы (?), 09:59 , 08-Мрт-21, (106)

Хотя это конечно чисто извернуться Штука когда есть набор данных которые надо , ыы (?), 10:05 , 08-Мрт-21, (107)

Нет никакой системы, чтобы говорить о проектировании её Это процесс разработки , Ordu (ok), 11:36 , 08-Мрт-21, (111)

Чем-то напоминает если вам нужны версии, просто делайте архивы , Аноним (139), 12:51 , 09-Мрт-21, (139)

Да что-то ничего крутого ни в гит ни в стиле гит нет Последние откровенным ма, Аноньимъ (ok), 01:33 , 08-Мрт-21, (76) –2

Вроде не такая сложная идея, но прямо историческая крутость , Kusb (?), 12:40 , 07-Мрт-21, (4) +4

Про крутость пока неизвестно Просто сказать у нас версии данных мало, нужно, Gogi (??), 13:59 , 07-Мрт-21, (13) +5

Мы засунули вам абстракцию в абстракцию, чтобы пока вы используете абстракцию, м, Синдарин (?), 00:30 , 08-Мрт-21, (70) +4

Название настораживает Хотя Go , Онаним (?), 13:34 , 07-Мрт-21, (9) –4
Что за чушь Причём тут git вообще Или вы больше не знаете DVCS Почему не в , Gogi (??), 13:52 , 07-Мрт-21, (11) –3

https github com dolthub dolt blob master README md Dolt is a SQL database tha, RNZ (ok), 14:09 , 07-Мрт-21, (22) +5

Фанфики, которые мы заслужили А по сабжу - если взлетит, то будет интересно посл, Аноним (45), 18:31 , 07-Мрт-21, (45) +3

Зачем нам сын Git x MySQL, если можно внука Git x Bitcoin x MongoDB OrbitDB , Аноним (49), 20:18 , 07-Мрт-21, (49)

Мичурин, залогиньтесь , YetAnotherOnanym (ok), 21:39 , 07-Мрт-21, (54)
Откуда берутся все эти уроды , Аноньимъ (ok), 01:36 , 08-Мрт-21, (77) +1

Сон разума рождает чудовищ с , ыы (?), 09:48 , 08-Мрт-21, (104) +3

стул в пепел , имятакое (?), 14:41 , 07-Мрт-21, (28) +2

Без биндингов к питону a-la SQLite без клиент-серверного говна, чтобы всё было, Аноним (49), 13:56 , 07-Мрт-21, (12)

Вообще-то игогошечка был сделан для того чтобы твой бидон прихлопнуть нафиг И с, Аноним (17), 14:05 , 07-Мрт-21, (17) –2

Совершенно разные вещи Одна из главных фич всех скриптовых языков - это REPL А, Аноним (49), 14:21 , 07-Мрт-21, (26) +1

Скрыто модератором, Аноним (-), 14:51 , 07-Мрт-21, (29) –2
Как это связано Для Haskell есть REPL, хотя он компилируемый по самое небалуй , Аноним (32), 15:04 , 07-Мрт-21, (32)

Я сказал эффективного Ты наверное этим REPLом для C , основанном на устаревш, Аноним (49), 16:38 , 07-Мрт-21, (40) –3

Ну, понимаешь, твоя эффективность продакшну очень дорого обходится, сервера ба, Аноним (-), 23:15 , 07-Мрт-21, (60)

Учитывая что серверов у гугла как грязи, и сама архитектура построена на идее де, ыы (?), 00:13 , 08-Мрт-21, (68)

Сервер может быть дешёвым, но датацентры стоят дорого, особенно когда жрут много, Аноним (81), 03:01 , 08-Мрт-21, (81) +1

Я думаю упрощение труда программиста будет и дальше превалировать над ценой обор, ыы (?), 09:21 , 08-Мрт-21, (90)

Гонять на том же парке серверов в разы большую нагрузку без докупки дешевых се, Аноним (-), 09:20 , 08-Мрт-21, (88)

А вы знаете разницу в производительности дешевого сервера и дорогого В пересче, ыы (?), 09:25 , 08-Мрт-21, (92)

мы знаем, а вам гуглить придется , B (?), 23:17 , 08-Мрт-21, (128)
В пересчете на ватт еще не забудьте Когда некто оперирует целыми датацентрами, , Аноним (-), 23:43 , 08-Мрт-21, (129) –2

Это в веб-сервисах Я же программер на питоне и плюсах программ для десктопа и д, Аноним (49), 08:37 , 08-Мрт-21, (85)

Ага, питон - таки да, для сайентистов с одноразовыми макетами А для остального , Аноним (-), 09:22 , 08-Мрт-21, (91) –1

В продакшне видите ли скорость приоритетнее И черт с ним, с REPLом нахрен он, Аноним (-), 23:10 , 07-Мрт-21, (59)

Да нахрена он вообще Та же беда, что и с экспериментами в командной строке шелл, CrazyAlex (?), 07:35 , 08-Мрт-21, (84)

Ну вон какой-то дата-саентолог вылез Ему может что-то такое и пригодится А , Аноним (-), 09:28 , 08-Мрт-21, (95)

go run Что значит эффективный REPL Вот такой что-ли https github com moteme, RNZ (ok), 14:30 , 08-Мрт-21, (117)

А они есть https github com dolthub doltpy, Ted (?), 15:35 , 07-Мрт-21, (34)

Он стартует серверный процесс и подключается к нему по сети Значит будет оверхе, Аноним (49), 16:29 , 07-Мрт-21, (39) –3

Питон сам тормозной как трактор, так что смысла то все это оптимизировать Чтобы, Аноним (-), 23:18 , 07-Мрт-21, (61)

Тоже узко Питон позволяет подключать сишные библиотеки для числодробилок Если , kai3341 (ok), 01:21 , 08-Мрт-21, (75) +1

База данных, наверное, не числодробилка Да, и используя базу на го логично и бэк, Аноним (-), 09:30 , 08-Мрт-21, (96)

Мне даже возразить нечего -- слишком узко мыслите, не поймёте-сс Что делать, есл, kai3341 (ok), 01:02 , 08-Мрт-21, (73)

Смузихлебы способны и не на такое Это вы тут узко мыслите Нужно все разделить н, Аноньимъ (ok), 01:50 , 08-Мрт-21, (78)

К -- Конструктивность Сразу видно -- Инженерище thread, kai3341 (ok), 02:00 , 08-Мрт-21, (80)

Перезапустить Многопроцессность не нужна, у нас bottleneck при импорте - случайн, Аноним (49), 09:16 , 08-Мрт-21, (87)

Отлично Опыта работы с БД у вас нет -- иначе вы бы знали, что такой фокус закон, kai3341 (ok), 22:13 , 08-Мрт-21, (126)

Это только если отключён журнал Отключение журнала повысит производительность, , Аноним (146), 10:01 , 10-Мрт-21, (146)

Это забавный тонкий момент Журнал как раз позволяет восстановить структуру в ав, kai3341 (ok), 15:03 , 11-Мрт-21, (149)

Актуальная проблема для питонистов, только обычно падает с трехэтажным стектрейс, Аноним (-), 09:32 , 08-Мрт-21, (97) +1

Оказывается, проблема питона в стэктрейсах Вы их боитесь Они вас обидели Ярлык, kai3341 (ok), 21:18 , 08-Мрт-21, (125) –1

Когда все резко и внезапно обламывается с адским стэктрейсом - это неприятно, да, Аноним (-), 23:47 , 08-Мрт-21, (130) +1

А чего тогда не Golt P, Аноним (17), 14:03 , 07-Мрт-21, (14)

go it do it , B (?), 00:44 , 09-Мрт-21, (133)

Сейчас чуть дотошнее прочёл и прям взрыв мозга Клонировать таблицы Ну, допустим, Gogi (??), 14:04 , 07-Мрт-21, (15) –2

Вот тоже интересно что-нибудь серьезней обычного bcp они сделали , Аноним (42), 17:14 , 07-Мрт-21, (42)
Если идеи, заложенные в эту СУБД, настолько ортогональны всему, что ты когда-то , YetAnotherOnanym (ok), 21:46 , 07-Мрт-21, (55) –1

Скажите пожалуйста, а зачем версионировать таблицы БД со статистикой о коронави, ыы (?), 22:44 , 07-Мрт-21, (57) +1

Это похоже попытка сделать темпоральную БД Компании разные пыжились но как я по, Аноним (42), 23:55 , 07-Мрт-21, (64)

InfluxDB называется Вон работает как лошадь - метрики мониторинга пишет , ыы (?), 00:07 , 08-Мрт-21, (66) +1

Больше имело в виду полностью скуль база На которой можно делать всё тоже самое, Аноним (42), 01:19 , 08-Мрт-21, (74)

зачем , ыы (?), 09:28 , 08-Мрт-21, (94)

Затем же зачем и всё остальное - упростить работу Всё в одной таблице а заморач, Аноним (42), 11:39 , 08-Мрт-21, (113)

А почему нельзя при изменении одной ячейки считать всю таблицу со старым значени, YetAnotherOnanym (ok), 00:44 , 08-Мрт-21, (71) +1

Это все элементарно делается уже имеющимися технологиями , ыы (?), 09:33 , 08-Мрт-21, (98)

Доски тоже можно прикреплять деревянными штырьками, забивая их булыжником Но гв, YetAnotherOnanym (ok), 14:30 , 08-Мрт-21, (116) +1

Именно так, всякие dolt и прочие булыжники не нужны , Аноним (-), 16:25 , 09-Мрт-21, (143)

Интересно, что у БД есть история с 2016 года И до 2018 года ей занимались абсол, Аноним (18), 14:05 , 07-Мрт-21, (18) +3
О, что-то интересное, да ещё и на Golang Спасибо большое , Иваня (?), 15:45 , 07-Мрт-21, (35) –5
с одной стороны инт , а с другой стороны аназачем ну вот реально а на зачем , DIO (?), 16:42 , 07-Мрт-21, (41) –1

Распределённый Интернет, не нужно быть постоянно связанным всеми со всем миром , Kusb (?), 19:49 , 07-Мрт-21, (48)

dictionary cambridge org 8250 dictionary 8250 english 8250 doltdolt def, anonimous (?), 20:37 , 07-Мрт-21, (52) +2

Я понял, это шутку к 1му апреля готовят , Аноньимъ (ok), 01:56 , 08-Мрт-21, (79)

Не, ну а чего Разработчики честны относительно аудитории У го и на логотипе, в, Аноним (-), 23:48 , 08-Мрт-21, (131)

Here we go again, Аноним (53), 21:26 , 07-Мрт-21, (53) +2
Сначала я подумал о, круто, какая свежая идея , а потом подумал ещё и понял, чт, Аноним (56), 22:24 , 07-Мрт-21, (56)

Мне вот тоже непонятно чем выборка по актуальному признаку при физическом отсут, ыы (?), 22:54 , 07-Мрт-21, (58) +1

Допустим, у вас датасет плюс-минус один, но может пополняться А состояний, в ко, Crazy Alex (ok), 09:26 , 08-Мрт-21, (93)

Это просто дурно спроектированная база данных и ветер в консерватории программис, ыы (?), 09:35 , 08-Мрт-21, (101)

Угу, и git не нужен, потому что бизнесу он бесполезен , Ordu (ok), 03:53 , 08-Мрт-21, (82)

После того как я увидел ТОПА ТРАНСНАЦИОНАЛЬНОЙ КОРПОРАЦИИ сцуко регающегося на г, Аноним (-), 09:35 , 08-Мрт-21, (100) +1
Это вы уж сами придумали Тут проблема не в конкретном гите, а в том, что будет в, Аноним (56), 16:29 , 08-Мрт-21, (120)

Узкой области применений Data science растёт как на дрожжах, и я бы не назва, Ordu (ok), 17:11 , 08-Мрт-21, (121)

Сообщение набрано и отправлено, квиток от внешней системы ещё не получен, и тут,, Аноним (56), 01:26 , 09-Мрт-21, (134)

То же самое будет и с сорцами в git, ежели ты, проводя серию связанных изменений, Ordu (ok), 04:07 , 09-Мрт-21, (136)

От форков сорцов в гит ни горячо, ни холодно, потому что это никак не влияет на , Аноним (56), 09:06 , 09-Мрт-21, (137) –1

Ты про реальность, с точки зрения бизнеса Когда программист потратил рабочий де, Ordu (ok), 09:15 , 09-Мрт-21, (138)

От того, что у программиста не компилируется, реальности пофигу , Аноним (56), 17:30 , 09-Мрт-21, (144)

От того, что проводки не проводятся реальности тоже пофигу , Ordu (ok), 00:03 , 10-Мрт-21, (145)

Да-да, интересно, как будет брызгать слюною конкретный Ordu, когда его платежи , Аноним (56), 09:04 , 11-Мрт-21, (147)

Всегда меня озадачивало, как люди могут жить в своём информационном пузырьке и н, Ordu (ok), 11:03 , 11-Мрт-21, (148)

Речь не об однократном откате, а о том, что для разных ситуаций правильное ко, Crazy Alex (ok), 09:21 , 08-Мрт-21, (89)

При исследовании - подмена данных ради хорошего результата- это все таки кримин, ыы (?), 09:38 , 08-Мрт-21, (103) +1

Без этой подмены ничего не работает В сыром датасете всегда куча мусора И его , Ordu (ok), 11:39 , 08-Мрт-21, (112)

Если факты не подтверждают теорию, от них нужно избавиться cледствие из зако, Аноним (-), 23:52 , 08-Мрт-21, (132)

Во-первых, всегда есть первичная обработка - выкинуть сильные выбросы, явный мус, CrazyAlex (?), 19:53 , 08-Мрт-21, (124)

Идея интересная, но чем в данном случае будет merge OK, допустим это слияние дв, Аноним (65), 00:01 , 08-Мрт-21, (65)
Мне кажется, что база данных, в которой определенный scn или момент времени имее, ыы (?), 00:11 , 08-Мрт-21, (67)

Это если вы там бахгалтерию или регистрантов на сайте храните А для исследовани, Crazy Alex (ok), 09:33 , 08-Мрт-21, (99)

По моему это придумывание задач под забавную игрушку попавшую в руки , ыы (?), 09:36 , 08-Мрт-21, (102)

У приличных баз данных есть такая штука как флэшбек И от шо я скажу- если вам, ыы (?), 00:16 , 08-Мрт-21, (69) +2
Кстати, а почему они не написали с точностью до наоборот - прикрутить к git- обе, ыы (?), 09:50 , 08-Мрт-21, (105)

Да именно так берем обычный немодифицированный git любой берем обычный немодифи, ыы (?), 10:49 , 08-Мрт-21, (109)

Написано на Go Как это чудо будет вести себя под высокими нагрузками с большим , Прохожий (??), 12:54 , 08-Мрт-21, (114) +1
Почему не на блохчлене Даешь гит овер блохчлен субд , msgod (ok), 14:49 , 08-Мрт-21, (118)
Манипулировать данными это всегда хорошо , Аноним (119), 15:43 , 08-Мрт-21, (119)
Я помню, что хотел такую штуку написать, но уже не помню зачем , Аноним (122), 18:47 , 08-Мрт-21, (122)

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

2. Сообщение от Msk20 (?), 07-Мрт-21, 12:36 +6 +/–

Круто. По крайней мере задумка (хотя бы она).
Что-то инновационное!

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #36, #76

4. Сообщение от Kusb (?), 07-Мрт-21, 12:40 +4 +/–

Вроде не такая сложная идея, но прямо историческая крутость.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13

9. Сообщение от Онаним (?), 07-Мрт-21, 13:34 –4 +/–

Название настораживает.
Хотя Go...

Ответить | Правка | Наверх | Cообщить модератору

11. Сообщение от Gogi (??), 07-Мрт-21, 13:52 –3 +/–

> версионирования данных в стиле Git
Что за чушь?? Причём тут git вообще? Или вы больше не знаете DVCS? Почему не "в стиле Mercurial"? В чём сходство именно с git? Более того - в чём вообще сходство с DVCS? Может, такая СУБД вообще сродни SVN! Аффтар, не бросайся терминами зазря - сначала выясни вопрос. Это обычная "версионная СУБД", хотя с большим количеством вопросов, "как оно работает". В том смысле, будет ли полезна реализация этой версионности в применении уже к реальным приложениям.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #22, #28

12. Сообщение от Аноним (49), 07-Мрт-21, 13:56 +/–

Без биндингов к питону a-la  SQLite (без клиент-серверного говна, чтобы всё было в одном процессе и потоке) - не нужно.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #17, #34

13. Сообщение от Gogi (??), 07-Мрт-21, 13:59 +5 +/–

Про "крутость" пока неизвестно. Просто сказать "у нас версии данных" мало, нужно знать ЧТО ИМЕННО версионируется, насколько легко это использовать и где это использовать вообще.
Ну вот вопросы навскидку:
1. Можно ли версионировать поле отдельной записи? Или это относится только к записи целиком?
2. Каким является атомарный коммит? Все изменения во всех таблицах? Изменения в одной таблице? Изменения конкретной записи? Поля?
3. Можно ли применить отдельно взятый "коммит" к чужеродной СУБД, не перекачивая всю историю изменений?
4. Можно ли из коммита применить достать изменения только конкретной таблицы?
5. Можно ли "схлопнуть" изменения до уровня минимального CRUD?
вопросов много и далеко не все однозначны. Подобные "версионники" имеет смысл делать сразу к конкретному применению, потому что иначе вопросы будут неразрешимы.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #70

14. Сообщение от Аноним (17), 07-Мрт-21, 14:03 +/–

А чего тогда не Golt? :P

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #133

15. Сообщение от Gogi (??), 07-Мрт-21, 14:04 –2 +/–

Сейчас чуть дотошнее прочёл и прям взрыв мозга:
Клонировать таблицы? Ну, допустим! И ЧТО ДАЛЬШЕ? Как писать запрос?
SELECT * FROM T(версия 1)
LEFT JOIN T2(версия 17)
так шт0ле??
А если в оригинальную таблицу внесли данные, а в клоне вообще добавили NON-NULL поле - как делать merge? Ведь non-null надо чем-то заполнять! (и молись, если это не FK!)
Короче, есть серьёзное подозрение, что "версионирование" там настолько убогое, что хватит максимум на "снэпшот" состояния в один момент времени - ну так это и обычный backup делает!

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #42, #55

17. Сообщение от Аноним (17), 07-Мрт-21, 14:05 –2 +/–

Вообще-то игогошечка был сделан для того чтобы твой бидон прихлопнуть нафиг. И собственно в вебне это и происходит везде, особенно в гугеле.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #26

18. Сообщение от Аноним (18), 07-Мрт-21, 14:05 +3 +/–

Интересно, что у БД есть история с 2016 года. И до 2018 года ей занимались абсолютно другие люди https://github.com/dolthub/dolt/graphs/contributors, которые сейчас не состоят в команде https://www.dolthub.com/team
А текущая команда появилась в конце 2018 и продолжила работу над уже существующим проектом и судя по всему тогда и появился бренд DoltDB (2018-11-30 дата регистрации домена).

Ответить | Правка | Наверх | Cообщить модератору

22. Сообщение от RNZ (ok), 07-Мрт-21, 14:09 +5 +/–

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ообщить модератору
Родитель: #11 Ответы: #45

26. Сообщение от Аноним (49), 07-Мрт-21, 14:21 +1 +/–

Совершенно разные вещи. Одна из главных фич всех скриптовых языков - это REPL. А Go - компилируемый, эффективного REPLа там нет и не будет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #29, #32, #59, #117

28. Сообщение от имятакое (?), 07-Мрт-21, 14:41 +2 +/–

стул в пепел?)))

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

29. Сообщение от Аноним (-), 07-Мрт-21, 14:51 –2 +/–

> Совершенно разные вещи. Одна из главных фич всех скриптовых языков - это
> REPL. А Go - компилируемый, эффективного REPLа там нет и не будет.
С другой стороны, игогошечка по сравнению с пихоном быстр как понос и для продакшнов это аргумент. И, собственно, в продакшне REPL нафиг не упал. Игрулька для научно-экспериментальных макетчиков, которые не программисты и продакшна не имеют, так что и софт у них под стать оборудованию. Продакшн в вебе - не установка в лабе, через месяц не демонтируют. Так что running costs роялят. А докупать сервера может задолбаться даже гугл.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

32. Сообщение от Аноним (32), 07-Мрт-21, 15:04 +/–

>А Go - компилируемый, эффективного REPLа там нет и не будет.
Как это связано? Для Haskell есть REPL, хотя он компилируемый по самое небалуй. Даже для C/C++ этот ваш REPL был на базе LLVM.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #40

34. Сообщение от Ted (?), 07-Мрт-21, 15:35 +/–

А они есть.
https://github.com/dolthub/doltpy

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #39

35. Сообщение от Иваня (?), 07-Мрт-21, 15:45 –5 +/–

О, что-то интересное, да ещё и на Golang. Спасибо большое!

Ответить | Правка | Наверх | Cообщить модератору

36. Сообщение от Урри (ok), 07-Мрт-21, 16:01 –2 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #43, #47, #51, #83, #139

39. Сообщение от Аноним (49), 07-Мрт-21, 16:29 –3 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #61, #73

40. Сообщение от Аноним (49), 07-Мрт-21, 16:38 –3 +/–

Я сказал "эффективного". Ты наверное этим REPLом для C++, основанном на устаревшей LLVM (5, когда мой код компилируется Clang 13), не пользовался. Оно и к лучшему, он почти бесполезен, единственный толк от него - когда нужно шаблоны отладить, ибо компилятор такую простыню в сообщениях об ошибках выдаёт (после задержки компиляции), что пожалеешь, что вообще с этими шаблонами и вообще с C++ связался. Repl же отладить шаблоны немного помогает, но крашится часто и память жрёт. Для кода он императивного себя не оправдывает.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #60

41. Сообщение от DIO (?), 07-Мрт-21, 16:42 –1 +/–

с одной стороны инт. , а с другой стороны "аназачем"? ну вот реально а на зачем?! ради интереса или профита то да но вот где это использовать и реальное практическое применение какое? при разработке софта есть миграции и откаты и т.д. работает (касательно структуры), касательно данных никто бекапы не отменял. Смешение технологий конечно оригинально но сильно непонятен смысл т.е. с какой проблемой столкнулись что натолкнуло на создание сего , чего не хватало. т.е. вариантов аналогичного решения типа SQL + что-то (тут варианты в зависимости от задачи и нужного результата) есть. Всунутое в один стакан навевает на большую нестабильность системы в целом. Пожуем увидим...

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #48

42. Сообщение от Аноним (42), 07-Мрт-21, 17:14 +/–

Вот тоже интересно что-нибудь серьезней обычного bcp они сделали....

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

43. Сообщение от tim2k (ok), 07-Мрт-21, 17:27 –4 +/–

А если приложение не поддерживает  дополнительный столбец? Очень много систем с закрытым кодом, к сожалению, есть на свете.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #46, #50

45. Сообщение от Аноним (45), 07-Мрт-21, 18:31 +3 +/–

>It's like Git and MySQL had a baby!
Фанфики, которые мы заслужили.
А по сабжу - если взлетит, то будет интересно послушать трустори про джунов, которые запушили в мастер или щелнули reset --hard где не надо.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #49

46. Сообщение от Annoynymous (ok), 07-Мрт-21, 18:40 +4 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

47. Сообщение от Msk20 (?), 07-Мрт-21, 18:42 –2 +/–

Что-то добавлять. к КАЖДОЙ. А таблиц в БД десятки. Менять много. Так что не так уж и легко.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #62

48. Сообщение от Kusb (?), 07-Мрт-21, 19:49 +/–

Распределённый Интернет, не нужно быть постоянно связанным всеми со всем миром.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

49. Сообщение от Аноним (49), 07-Мрт-21, 20:18 +/–

Зачем нам сын Git x MySQL, если можно внука (Git x Bitcoin) x MongoDB = OrbitDB?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #54, #77

50. Сообщение от adolfus (ok), 07-Мрт-21, 20:28 +6 +/–

Значит оно не поддерживает и СУБД Dolt. О чем вообще разговор?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #108

51. Сообщение от минона (?), 07-Мрт-21, 20:36 +/–

Нет, не совсем. Подобный подход позволяет версионифицировать данные в одной таблице.
Но, как правило, таблиц много, и данные в них связаны. Соответственно, для организации _среза_ данных приходится городить заметно более сложную структуру. Для этого, конечно, новый движок не требуется, достаточно обычного Постгреса. И, конечно, требуется инструмент для конструирования многоэтажных запросов (по опыту, там одних CVE-шек не меньше трех).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #63

52. Сообщение от anonimous (?), 07-Мрт-21, 20:37 +2 +/–

dictionary.cambridge.org › dictionary › english › dolt
dolt definition: 1. a stupid person 2. a stupid person.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #79

53. Сообщение от Аноним (53), 07-Мрт-21, 21:26 +2 +/–

Here we go again

Ответить | Правка | Наверх | Cообщить модератору

54. Сообщение от YetAnotherOnanym (ok), 07-Мрт-21, 21:39 +/–

Мичурин, залогиньтесь.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

55. Сообщение от YetAnotherOnanym (ok), 07-Мрт-21, 21:46 –1 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #57

56. Сообщение от Аноним (56), 07-Мрт-21, 22:24 +/–

Сначала я подумал "о, круто, какая свежая идея", а потом подумал ещё и понял, что фигня. И вот почему.
Откат в любой базе данных подразумевает откат на некое консистентное состояние, в котором бизнес (именно бизнес!) транзакции завершены и подтверждены. Ну там платежка например ушла в банк и есть подтверждение, что она принята в работу. Или платежка точно не ушла и не уйдёт автоматически, если случится откат на предыдущий бэкап.
Чтобы решить эту задачу, не нужно городить никаких (псевдо) гитов, это делается логикой самого приложения.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #58, #82, #89

57. Сообщение от ыы (?), 07-Мрт-21, 22:44 +1 +/–

Скажите пожалуйста, а зачем версионировать таблицы БД "со статистикой о коронавирусе"?
Мне казалось что версионировать надо данные а не таблицы... Кроме службы безопасности кому это надо? А для службы безопасности есть такая штука как аудит...
Например есть отчет о состоянии ковид на 1 января... и есть такой же отчет за 5 января. Это разные версии отчета, которые хранятся в виде связанных записей в одной и той же таблице и извлекаются по признаку даты отчета.
Зачем нужна версия самой таблицы? То есть традиционным способом, мы, чтобы получить отчет за 1 января- должны будем восстановить базу из бэкапа за 2 число? Вместо того чтобы просто сделать выборку по данным по признаку?
В чем смысл?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #64, #71

58. Сообщение от ыы (?), 07-Мрт-21, 22:54 +1 +/–

Мне вот тоже непонятно  чем выборка по актуальному признаку при физическом отсутствии лишних данных (состояние базы в некий момент времени) лучше выборки тем же данным при наличии еще других данных в таблице?
Ну кроме размера области поиска конечно :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #93

59. Сообщение от Аноним (-), 07-Мрт-21, 23:10 +/–

> Совершенно разные вещи. Одна из главных фич всех скриптовых языков - это
> REPL. А Go - компилируемый, эффективного REPLа там нет и не будет.
В продакшне видите ли скорость приоритетнее. И черт с ним, с REPLом... нахрен он вебне и микросервисам, по большому счету?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #84

60. Сообщение от Аноним (-), 07-Мрт-21, 23:15 +/–

> Я сказал "эффективного".
Ну, понимаешь, твоя "эффективность" продакшну очень дорого обходится, сервера бабок стоят. Вот они питонистов и начали уходить. Вплоть до того что вот, крупный продакшн в виде гугла даже свой ЯП расперся сделать. А остальным уже так напрягаться не надо, достаточно програмеров сменить, на игогохе уже изрядо вебманки шпрехает, это не проблема совершенно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #68, #85

61. Сообщение от Аноним (-), 07-Мрт-21, 23:18 +/–

> Он стартует серверный процесс и подключается к нему по сети. Значит будет
> оверхед на переключение контекста, оверхед на сокет, оверхед на сериализацию, никакого
> прямого доступа к отображениям в памяти
Питон сам тормозной как трактор, так что смысла то все это оптимизировать? Чтобы знатно попахать с результатом близким к нулю?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #75

62. Сообщение от ыы (?), 07-Мрт-21, 23:42 +4 +/–

А вы думаете как партицирование делается? Не только на каждую таблицу.. а каждую строку...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

63. Сообщение от ыы (?), 07-Мрт-21, 23:45 +/–

> для организации _среза_ данных
мы строим sql  запрос... Зачем перед этим  организовывать физическое присутствие определенных данных?
Почему нельзя просто делать это тем же sql запросом? Почему надо для этого запроса каждый раз поднимать базу из бэкапа на какоето число или scn??

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #72

64. Сообщение от Аноним (42), 07-Мрт-21, 23:55 +/–

Это похоже попытка сделать темпоральную БД. Компании разные пыжились но как я погляжу это не взлетело.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #66

65. Сообщение от Аноним (65), 08-Мрт-21, 00:01 +/–

Идея интересная, но чем в данном случае будет merge. OK, допустим это слияние двух изменений в какое-то третье изменение включающее оба. На графе всё норм, но как будет выполняться хотя бы простейшее из них.
Например, с текстом всё более или менее ясно - строи упорядочены и привязаны к контексту предыдущих и последующих строк.
В таблицах в общем случае порядка нет и строки в общем случае не связаны между собой. Как можно тут смержить автоматом даже две вставки.
Тут либо придётся вводить обязательные кластеризованные первичные ключи, которые к тому же возможно не должны быть строго суррогатными. Это немного ломает красоту исходной идеи.
А без слияний с достаточным уровнем автоматики всё это мало что даёт.
Хотя возможно в рамках разработки появится какой-то новый инструмент для слияний структурированных данных, даже если в целом сама БД совсем не взлетит.

Ответить | Правка | Наверх | Cообщить модератору

66. Сообщение от ыы (?), 08-Мрт-21, 00:07 +1 +/–

InfluxDB называется... Вон работает как лошадь - метрики мониторинга пишет..

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #74

67. Сообщение от ыы (?), 08-Мрт-21, 00:11 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #99

68. Сообщение от ыы (?), 08-Мрт-21, 00:13 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #81, #88

69. Сообщение от ыы (?), 08-Мрт-21, 00:16 +2 +/–

>При этом Dolt скорее является инструментом для манипулирования данными, чем системой обработки запросов
У приличных баз данных есть такая штука как флэшбек... И от шо я скажу- если вам часто надо делать флэшбек- вы чтото в принципе делаете неправильно...

Ответить | Правка | Наверх | Cообщить модератору

70. Сообщение от Синдарин (?), 08-Мрт-21, 00:30 +4 +/–

Мы засунули вам абстракцию в абстракцию, чтобы пока вы используете абстракцию, могли получить абстракцию.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

71. Сообщение от YetAnotherOnanym (ok), 08-Мрт-21, 00:44 +1 +/–

А почему нельзя при изменении одной ячейки считать всю таблицу со старым значением одной версией, а с новым значением - другой? Где-нибудь сказано, что при этом должны физически клонироваться на диске все оставшиеся неизменными ячейки?
> для службы безопасности есть такая штука как аудит
Ну дык вот для него же, например.
> есть отчет о состоянии ковид на 1 января... и есть такой же отчет за 5 января
А потом в отчёте за 5 января вдруг оказываются некие более другие цифры. СМИ истерят, биржи лихорадит, некие люди делают огромные деньги, потому что ждали этих новостей, а потом админ не только одной-единственной командой восстанавливает правильное значение статистики за 5 января, но и столь же быстро выдаёт полный отчёт для ФБР и Комиссии по ценным бумагам с указанием всех подробностей о внесении искажённых данных в БД.
Или представь себе ситуацию, когда ты приходишь домой, а там чужие люди суют тебе в нос свежую выписку из ЕГРП и предлагают собрать манатки и валить по-хорошему.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #98

72. Сообщение от минона (?), 08-Мрт-21, 01:00 +1 +/–

Возможно, я не совсем понял вопрос, но в системах, для которых нужно манипулировать данными в стиле Git (см. топик), интересно не просто состояние какой-то одной записи в табличке, а определенного подмножества данных, соответствующих нужному состоянию. Точно так же, вы в Git (а равно как и в SVN и любой другой SCM, не считая RCS и CVS) имеете дело не с отдельным файлом, а с (под)множеством файлов, соответствующих определенному коммиту.
То есть, при конструировании запроса вы сначала имеете требуемое состояние (коммит, грубо говоря), а потом под него выгребаете нужные записи с нужными связями. Но опять-таки, связи интересны не абы какие, а только те, которые существовали ровно на момент выбранного коммита.
По итогу, типичный запрос в базе для десятка-другого сущностей вполне тянет на половину странички или страничку текста в стандартном редакторе. В подобном запросе присутствуют несколько CTE-шек, ну и вообще, писать и читать такие штуки руками уже становится некомфортно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #86

73. Сообщение от kai3341 (ok), 08-Мрт-21, 01:02 +/–

>  Он стартует серверный процесс и подключается к нему по сети. Значит будет оверхед на переключение контекста, оверхед на сокет, оверхед на сериализацию, никакого прямого доступа к отображениям в памяти, да ещё и без гарантий завершения сервера, если клиентский процесс упадёт. Поэтому я мультипроцессинг так и не люблю.
Мне даже возразить нечего -- слишком узко мыслите, не поймёте-сс.
Что делать, если пользовательский процесс упадёт с сегфолтом посреди транзакции?
Как синхронизировать множество подключений? Через временный файл?
In-memory кэши хранить в каждом процессе, значит, свои? Как инвалидировать?
Или не кэшировать данные вовсе? Тогда что делать с производительностью?
Может, не зря индустрия БД запускает в отдельном процессе? Или миллионы опытных программистов ошибаются?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #78, #87, #97

74. Сообщение от Аноним (42), 08-Мрт-21, 01:19 +/–

Больше имело в виду полностью скуль база. На которой можно делать всё тоже самое, но ещё и выбирать в какой момент времени делать запрос. Инфлюкс с этим как-то не очень.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #94

75. Сообщение от kai3341 (ok), 08-Мрт-21, 01:21 +1 +/–

> Питон сам тормозной как трактор, так что смысла то все это оптимизировать? Чтобы знатно попахать с результатом близким к нулю?
Тоже узко. Питон позволяет подключать сишные библиотеки для числодробилок. Если вынести на python логику контроллера (которой овердохера и она часто меняется, но при этом сложной не является), то оверхед будет минимальным (см. профайлер). Если при этом ещё не тупить и использовать asyncio, то процессорное время на python-код будет минимальным
Я к чему. Не надо забивать гвозди микроскопом

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #96

76. Сообщение от Аноньимъ (ok), 08-Мрт-21, 01:33 –2 +/–

Да что-то ничего крутого ни в гит ни в "стиле гит" нет. Последние откровенным маразмом попахивает.
БД на жаваскрипте надеюсь написана?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

77. Сообщение от Аноньимъ (ok), 08-Мрт-21, 01:36 +1 +/–

Откуда берутся все эти уроды?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #104

78. Сообщение от Аноньимъ (ok), 08-Мрт-21, 01:50 +/–

Смузихлебы способны и не на такое. Это вы тут узко мыслите!
Нужно все разделить на микросервисы с персональными кешами и кеширующими микросервисами. И тогда взлетит!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #80

79. Сообщение от Аноньимъ (ok), 08-Мрт-21, 01:56 +/–

Я понял, это шутку к 1му апреля готовят.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #131

80. Сообщение от kai3341 (ok), 08-Мрт-21, 02:00 +/–

> Смузихлебы способны и не на такое. Это вы тут узко мыслите!
> Нужно все разделить на микросервисы с персональными кешами и кеширующими микросервисами. И тогда взлетит!
К -- Конструктивность. Сразу видно -- Инженерище!
/thread

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

81. Сообщение от Аноним (81), 08-Мрт-21, 03:01 +1 +/–

Сервер может быть дешёвым, но датацентры стоят дорого, особенно когда жрут много энергии и производят тепла. Закон Мура закончился, дальнейшее упрощения труда программистов начинает сказываться на цене обслуживания.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #90

82. Сообщение от Ordu (ok), 08-Мрт-21, 03:53 +/–

> Сначала я подумал "о, круто, какая свежая идея", а потом подумал ещё и понял, что фигня. И вот почему.
Угу, и git не нужен, потому что бизнесу он бесполезен.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #100, #120

83. Сообщение от 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, и рядом с ним программку, которая его обрабатывает. Таким образом я мог иметь историю того и этого рядом.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #106

84. Сообщение от CrazyAlex (?), 08-Мрт-21, 07:35 +/–

Да нахрена он вообще? Та же беда, что и с экспериментами в командной строке шелла - замучаешься контролировать состояние окружения. Поэтому я уже много лет всё мало-мальски сложное шелловское сразу пихаю в файлы, а просто командная строка - это для ps | grep какого-нибудь. И точно так же - никакого REPL, только нормальный файл с исходниками и Makefile рядом по возможности, чтобы повторяемо было, и желательно - не только мной

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #95

85. Сообщение от Аноним (49), 08-Мрт-21, 08:37 +/–

Это в веб-сервисах. Я же программер на питоне и плюсах программ для десктопа и дейта-саентист. Какие там у Гугла проблемы на хайлоад-серверах, обслуживающих клиентов, меня не очень волнует - мои приложения не обслуживают клиентов и не должны держать тысячи запросов в секунду, главный bottleneck у меня - это диск (потому что я жлоб и SSD брать не буду) и память. Они должны делать свое дело локально.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #91

86. Сообщение от ыы (?), 08-Мрт-21, 09:08 –1 +/–

Это все понятно. И точки зрения академического интереса - можно извернуться... Приведите пример осмысленной задачи решаемой таким образом?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #127

87. Сообщение от Аноним (49), 08-Мрт-21, 09:16 +/–

>Что делать, если пользовательский процесс упадёт с сегфолтом посреди транзакции?
Перезапустить.
>Как синхронизировать множество подключений? Через временный файл?
Многопроцессность не нужна, у нас bottleneck при импорте - случайное чтение и запись. Клиент один и только один. Если остальные клиенты подключаются во время импорта - значит их проблемы.

>In-memory кэши хранить в каждом процессе, значит, свои? Как инвалидировать? Или не кэшировать данные вовсе? Тогда что делать с производительностью?
Да, свои, но у нас только один процесс. Вопрос только в том, зачем вообще хранить свои кеши, если кеширование - это забота ОС, а забота разраба базы данных - иметь отображение на часть файла, которую надо кешировать?
>Может, не зря индустрия БД запускает в отдельном процессе? Или миллионы опытных программистов ошибаются?
У них другие задачи. Эта же база изначально позиционируется как база для хранения datasetов и заливки их на их dolthub. Для хранения datasetов нужна не сетевая база, а встраиваемая, можно вообще не базу, а HDF-файл.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #126

88. Сообщение от Аноним (-), 08-Мрт-21, 09:20 +/–

> Учитывая что серверов у гугла как грязи, и сама архитектура построена на
> идее дешевого сервера но зато быстро заменяемого - сентенция о проблеме
> несколько странной выглядит...
Гонять на том же парке серверов в разы большую нагрузку без докупки "дешевых" серверов - любому капиталисту нравится. Больше профита за те же деньги. Тем более что он один - дешевый. А когда их тысячи, и вопрос в том что датацентров надо в разы больше, это уже вообще совсем не дешево получается. И на этом фоне можно уже и свой ЯП сколхозить, оплатив несколько больших голов и построив вебмакак. Благо, у гугла не будет проблем с наймом новых, если старые заартачатся.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #92

89. Сообщение от Crazy Alex (ok), 08-Мрт-21, 09:21 +/–

Речь не об однократном откате, а о том, что для разных ситуаций "правильное" (консистентное, конечно) состояние - разное.
Зачем это надо - вопрос другой, но особого криминала не вижу - допустим, проводим какие-то статистические исследования или там психологию - батареи тестов, тупящие респонденты, что-то не вовремя данные получили, одна анкетка в один результат считается, дгугая - в три, и так далее. Иметь возможность форкать и мержить датасеты в этом плане было бы удобно, и действительно ровно так же, как и исходники под гитом, и с теми же плюшками - всё в принципе хранится в одном месте, но нормально аннотировано и есть инструменты для работы со всем деревом форков. Так-то и исходники можно в куче каталогов хранить и ручками или скриптами копировать - но неудобно.
Вот идея в том, чтобы эту логику (видать относительно чатсо используемую в каких-то контекстах)  вытащить вовне, а не делать каждый раз в приложении. А заодно - дать возможность нормально это администрировать извне - приложение может вообще не знать, что там за форки (благо, оно ещё и mysql-совместимое).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #103

90. Сообщение от ыы (?), 08-Мрт-21, 09:21 +/–

Я думаю упрощение труда программиста будет и дальше превалировать над ценой оборудования. а на тепле от датацентров выращивают карпов в обогреваемых прудах...  Но вообще говоря с этого момента разговор без цифр не имеет смысла.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

91. Сообщение от Аноним (-), 08-Мрт-21, 09:22 –1 +/–

> Это в веб-сервисах. Я же программер на питоне и плюсах программ для
> десктопа и дейта-саентист.
Ага, питон - таки да, для сайентистов с одноразовыми макетами. А для остального он... кхе-кхе. Поэтому гугель и запилил игогошечку. И да, искренне надеюсь что мне никогда не придется иметь дело с вашим софтом.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

92. Сообщение от ыы (?), 08-Мрт-21, 09:25 +/–

А вы знаете разницу в производительности дешевого сервера и дорогого?  В пересчете на один доллар, евро, мегафлоп или квадратный метр? Ну или хотя бы просто порядок величин представляете?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #128, #129

93. Сообщение от Crazy Alex (ok), 08-Мрт-21, 09:26 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #101

94. Сообщение от ыы (?), 08-Мрт-21, 09:28 +/–

>выбирать в какой момент времени делать запрос
зачем?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #113

95. Сообщение от Аноним (-), 08-Мрт-21, 09:28 +/–

> Да нахрена он вообще?
Ну вон какой-то дата-саентолог :) вылез. Ему может что-то такое и пригодится. А остальным оно натурально ни в п... ни в красну армию, по большому счету.
> много лет всё мало-мальски сложное шелловское сразу пихаю в файлы, а
> просто командная строка - это для ps | grep какого-нибудь.
Ну да. Поэтому я и понимаю пойнт шелла в таком качестве, но вот нахрен в этом качестве питон для меня загадка. В шелле это какая-то мелкая системная автоматизация по месту. Вызовом сторонних утилсов.
> И точно так же - никакого REPL, только нормальный файл с исходниками
> и Makefile рядом по возможности, чтобы повторяемо было, и желательно -
> не только мной
Питонисты антипод этого - чтобы повторить их смертельный номер, придется выискикать вот конкретно вон ту версию пихона. А на полшишечки в сторону и нате вам трейс на три экрана...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

96. Сообщение от Аноним (-), 08-Мрт-21, 09:30 +/–

> Тоже узко. Питон позволяет подключать сишные библиотеки для числодробилок.
База данных, наверное, не числодробилка?
> Я к чему. Не надо забивать гвозди микроскопом
Да, и используя базу на го логично и бэк на нем же делать, чтоли. А профайлить питон пусть будет кто-нибудь другой. Сами эти фекалии профайльте.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

97. Сообщение от Аноним (-), 08-Мрт-21, 09:32 +1 +/–

> Что делать, если пользовательский процесс упадёт с сегфолтом посреди транзакции?
Актуальная проблема для питонистов, только обычно падает с трехэтажным стектрейсом сам кусок питона, потому что при его кодинге гнали как на пожар и на всякие там отклонения от идеаа клали болт. А если там сеть упала, памяти не хватило или там что еще - УПС.
И в свете этого - ну не питонистам с их "обработкой ошибок" такими мелочами париться вообще. Понимаю если б сишники какие так зудели еще.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #125

98. Сообщение от ыы (?), 08-Мрт-21, 09:33 +/–

Это все элементарно делается уже имеющимися технологиями.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #116

99. Сообщение от Crazy Alex (ok), 08-Мрт-21, 09:33 +/–

Это если вы там бахгалтерию или регистрантов на сайте храните. А для исследований разных - отличная идея.
Для навороченных многоголовых коллекций (фотографии те же) - то же - то, что доктор прописал. Ну там - взял в базе фото теги для конкретной съёмки, добавил другие, пару-тройку выкинул и назвал это "выставка Х" - и у тебя осталась последовательность того, что делал чтобы этот наборчик получить. А потом когда захотел сделать "лучшее с выставок" - можешь проследить когда и как ты на эти выставки работы отбирал.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #102

100. Сообщение от Аноним (-), 08-Мрт-21, 09:35 +1 +/–

> Угу, и git не нужен, потому что бизнесу он бесполезен.
После того как я увидел ТОПА ТРАНСНАЦИОНАЛЬНОЙ КОРПОРАЦИИ сцуко регающегося на гитхабе с аргументом "там тусуется много кастомеров и они используют это!" - я в этом почему-то совсем не уверен.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

101. Сообщение от ыы (?), 08-Мрт-21, 09:35 +/–

> А состояний, ... - много,
Это просто дурно спроектированная база данных и ветер в консерватории программиста написавшего систему.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

102. Сообщение от ыы (?), 08-Мрт-21, 09:36 +/–

По моему это придумывание задач под забавную игрушку попавшую в руки...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99

103. Сообщение от ыы (?), 08-Мрт-21, 09:38 +1 +/–

> особого криминала не вижу
> проводим какие-то статистические исследования или там психологию - батареи тестов, тупящие респонденты,
При исследовании -  подмена данных ради хорошего результата- это все таки криминал :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #112, #124

104. Сообщение от ыы (?), 08-Мрт-21, 09:48 +3 +/–

Сон разума рождает чудовищ (с)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

105. Сообщение от ыы (?), 08-Мрт-21, 09:50 +/–

Кстати, а почему они не написали с точностью до наоборот - прикрутить к git- обертку для запросов на sql?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #109

106. Сообщение от ыы (?), 08-Мрт-21, 09:59 +/–

прикрутить к git- обертку для запросов на sql?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #107

107. Сообщение от ыы (?), 08-Мрт-21, 10:05 +/–

Хотя это конечно чисто извернуться :)
Штука когда есть набор данных которые надо вот так вот кидать туда сюда- называется коллекция. И необходимость привлечения  git для манипуляций с нею -это как раз пример дурно спроектированной системы с чудовищным оверхедом из за непродуманности.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #111

108. Сообщение от Аноним (108), 08-Мрт-21, 10:34 +/–

Dolt ~= MySQL на уровне протокола

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #110

109. Сообщение от ыы (?), 08-Мрт-21, 10:49 +/–

Да именно так:
берем обычный немодифицированный git (любой)
берем обычный немодифицированный postgresql (mssql, oracle)
берем драйвер к git
и линкуем нашу базу на postgresql к сырым данным на git.
вот собственно и все... обычная связка для интеграции. Если очень хочется...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105

110. Сообщение от ыы (?), 08-Мрт-21, 11:18 +/–

И где там вон тот "AS OF" ?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108

111. Сообщение от Ordu (ok), 08-Мрт-21, 11:36 +/–

> Хотя это конечно чисто извернуться :)
> Штука когда есть набор данных которые надо вот так вот кидать туда
> сюда- называется коллекция. И необходимость привлечения  git для манипуляций с
> нею -это как раз пример дурно спроектированной системы с чудовищным оверхедом
> из за непродуманности.
Нет никакой системы, чтобы говорить о проектировании её. Это процесс разработки. Постоянно возникают новые идеи, и 90% из них оказываются пустышкой. Но чтобы понять, что они пустышка, надо попробовать. Это так же как с программированием в незнакомой области. Если ты влезешь, например, в рендеринг векторной графики, не имея особо опыта в этом деле, ты будешь поначалу двигаться наощупь.  Пробовать разные подходы, и отказываться от них. И каждая попытка -- это бранч в git'е, может даже дерево бранчей, из которых ты потом может пару коммитов позаимствуешь, для того, чтобы начать новый бранч для нового подхода.
А оверхед не важен. Если ты занят машинным обучением, то этот оверхед ведь будет случаться, когда ты руками что-то там делаешь. Вот ты сейчас готовишь данные для следующего раунда обучения, и какая тебе разница, будут ли твои действия выполняться 0.0001 сек или 0.1 сек? Тут важнее твоё личное удобство. И если тебе удобно для этого использовать git, то почему бы и нет?
Не, если этот оверхед будет выливаться в 10 минут перелопачивания данных, то дааа... это перебор. Даже минута много. Хотя, если эта минута нужна одна, на каждый раунд обучения, который длится десять часов, ну и чё? Тут оверхед только с точки зрения эргономики важен.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

112. Сообщение от Ordu (ok), 08-Мрт-21, 11:39 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #132

113. Сообщение от Аноним (42), 08-Мрт-21, 11:39 +/–

Затем же зачем и всё остальное - упростить работу. Всё в одной таблице а заморачиваться дополнительными полями мне не надо. Сейчас есть одно ПО что текущие данные хранит в одних таблицах а потом уносит данные в исторические таблицы. И мне надо в запросах все таблички менять, если надо получить что было раньше. Ещё оно архивирует данные с некоторой периодичностью. Если в промежутке были изменения они не попадут в историческую таблицу. А тут все батарейки в комплекте.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

114. Сообщение от Прохожий (??), 08-Мрт-21, 12:54 +1 +/–

Написано на Go. Как это чудо будет вести себя под высокими нагрузками с большим количеством пользователей, интересно. Там же GC всё тормозить будет нещадно, как это случилось у дискорда, например.

И ещё. Как уже заметили, у приличных СУБД есть flashback - та же версионность по большому счёту. Так в чём, собственно, новшество?

Ответить | Правка | Наверх | Cообщить модератору

116. Сообщение от YetAnotherOnanym (ok), 08-Мрт-21, 14:30 +1 +/–

Доски тоже можно прикреплять деревянными штырьками, забивая их булыжником. Но гвозди и молоток лучше.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98 Ответы: #143

117. Сообщение от RNZ (ok), 08-Мрт-21, 14:30 +/–

> Совершенно разные вещи. Одна из главных фич всех скриптовых языков - это
> REPL. А Go - компилируемый, эффективного REPLа там нет и не
> будет.
go run ?
Что значит "эффективный REPL"?
Вот такой что-ли:
https://github.com/motemen/gore/raw/master/doc/screencast.gif

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

118. Сообщение от msgod (ok), 08-Мрт-21, 14:49 +/–

Почему не на блохчлене?
Даешь гит овер блохчлен субд.

Ответить | Правка | Наверх | Cообщить модератору

119. Сообщение от Аноним (119), 08-Мрт-21, 15:43 +/–

Манипулировать данными... это всегда хорошо.

Ответить | Правка | Наверх | Cообщить модератору

120. Сообщение от Аноним (56), 08-Мрт-21, 16:29 +/–

Это вы уж сами придумали.
Тут проблема не в конкретном гите, а в том, что будет в базе при манипуляциях в таблицах.
Как мне видится, обсуждаемая идея имеет смысл в очень узкой области применений, а именно, если таблицы друг с другом не связаны и их можно модифицировать независимо друг от друга. Примеры коллеги привели. В статистику поиграть допустим, уберем данные такие-то, потом другие. Ну да, удобно сохранять состояние при таких экспериментах.
А если (я всё про платежи) некое сообщение фигурирует в 20 таблицах (ну там история модификаций, передача по документообороту, уведомления всякие, взаимодействие с внешними приложениями), то как тут форкать и мержить отдельные записи в таблицах? Я, хоть дерись, не понимаю, как обеспечить консистентность данных в таком случае. Тут только откат помогает и ручная выверка.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #121

121. Сообщение от Ordu (ok), 08-Мрт-21, 17:11 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #134

122. Сообщение от Аноним (122), 08-Мрт-21, 18:47 +/–

Я помню, что хотел такую штуку написать, но уже не помню зачем.

Ответить | Правка | Наверх | Cообщить модератору

124. Сообщение от CrazyAlex (?), 08-Мрт-21, 19:53 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

125. Сообщение от kai3341 (ok), 08-Мрт-21, 21:18 –1 +/–

> Актуальная проблема для питонистов, только обычно падает с трехэтажным стектрейсом сам кусок питона, потому что при его кодинге гнали как на пожар и на всякие там отклонения от идеаа клали болт. А если там сеть упала, памяти не хватило или там что еще - УПС.
Оказывается, проблема питона в стэктрейсах. Вы их боитесь? Они вас обидели?
> И в свете этого - ну не питонистам с их "обработкой ошибок" такими мелочами париться вообще. Понимаю если б сишники какие так зудели еще.
Ярлыки.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #130

126. Сообщение от kai3341 (ok), 08-Мрт-21, 22:13 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #146

127. Сообщение от B (?), 08-Мрт-21, 23:11 +/–

>> Приведите пример осмысленной задачи решаемой таким образом?
а это уже троллинг на уровне детсада.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

128. Сообщение от B (?), 08-Мрт-21, 23:17 +/–

мы знаем, а вам  гуглить придется.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

129. Сообщение от Аноним (-), 08-Мрт-21, 23:43 –2 +/–

> А вы знаете разницу в производительности дешевого сервера и дорогого?  В
> пересчете на один доллар, евро, мегафлоп или квадратный метр? Ну или
> хотя бы просто порядок величин представляете?
В пересчете на ватт еще не забудьте. Когда некто оперирует целыми датацентрами, все это уже не пустой звук. И тут дорогим серверам совершенно нечем похвастаться. Оптимальный по энергии режим работы CMOS чипов - вовсе не топовая производительность, что бы там сцаный маркетинг не лечил. Но для этого надо понимать азы этой схемотехники, что сложновато для реднеков.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

130. Сообщение от Аноним (-), 08-Мрт-21, 23:47 +1 +/–

> Оказывается, проблема питона в стэктрейсах. Вы их боитесь? Они вас обидели?
Когда все резко и внезапно обламывается с адским стэктрейсом - это неприятно, да. И таки было достаточно неприятного опыта такого плана.
> Ярлыки.
Статистические наблюдения.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125

131. Сообщение от Аноним (-), 08-Мрт-21, 23:48 +/–

> Я понял, это шутку к 1му апреля готовят.
Не, ну а чего? Разработчики честны относительно аудитории. У го и на логотипе, видите ли, хомячок.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79

132. Сообщение от Аноним (-), 08-Мрт-21, 23:52 +/–

> Без этой подмены ничего не работает. В сыром датасете всегда куча мусора.
"Если факты не подтверждают теорию, от них нужно избавиться!" (cледствие из законов мерфи)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112

133. Сообщение от B (?), 09-Мрт-21, 00:44 +/–

go it != do it

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

134. Сообщение от Аноним (56), 09-Мрт-21, 01:26 +/–

> С форком вообще я не вижу никаких проблем даже потенциально
Сообщение набрано и отправлено, квиток от внешней системы ещё не получен, и тут, опачки, форк. Квиток приходит в другую ветку. Восстановили предыдущее состояния, а там квитка нет, и сообщение уехало второй раз. А на той стороне муфлоны его провели дважды, и списали, например вместо двух миллионов денег четыре. Ахрененно.
Я ж говорю, всё это хорошая вещь, но для специфических применений. Ну вот накидали в базу картинок и вертим туда сюда. Испортить довольно сложно, когда это вещь в себе. Но чтоит подвязать внешние взаимодействия...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #136

136. Сообщение от Ordu (ok), 09-Мрт-21, 04:07 +/–

>> С форком вообще я не вижу никаких проблем даже потенциально
> Сообщение набрано и отправлено, квиток от внешней системы ещё не получен, и
> тут, опачки, форк. Квиток приходит в другую ветку. Восстановили предыдущее состояния,
> а там квитка нет, и сообщение уехало второй раз. А на
> той стороне муфлоны его провели дважды, и списали, например вместо двух
> миллионов денег четыре. Ахрененно.
То же самое будет и с сорцами в git, ежели ты, проводя серию связанных изменений, форкнешь сорцы посередине серии, и продолжишь серию в одной из веток. В другой будут скорее всего некомпилируемые сорцы. Это фича, а не баг.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #137

137. Сообщение от Аноним (56), 09-Мрт-21, 09:06 –1 +/–

От форков сорцов в гит ни горячо, ни холодно, потому что это никак не влияет на реальность.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #138

138. Сообщение от Ordu (ok), 09-Мрт-21, 09:15 +/–

> От форков сорцов в гит ни горячо, ни холодно, потому что это
> никак не влияет на реальность.
Ты про реальность, с точки зрения бизнеса? Когда программист потратил рабочий день, на то, чтобы понять почему оно не компилируется -- это вообще-то денег стоит.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #144

139. Сообщение от Аноним (139), 09-Мрт-21, 12:51 +/–

Чем-то напоминает: если вам нужны версии, просто делайте архивы.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

143. Сообщение от Аноним (-), 09-Мрт-21, 16:25 +/–

> Но гвозди и молоток лучше.
Именно так, всякие dolt и прочие булыжники не нужны.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116

144. Сообщение от Аноним (56), 09-Мрт-21, 17:30 +/–

От того, что у программиста не компилируется, реальности пофигу.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #145

145. Сообщение от Ordu (ok), 10-Мрт-21, 00:03 +/–

> От того, что у программиста не компилируется, реальности пофигу.
От того, что проводки не проводятся реальности тоже пофигу.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144 Ответы: #147

146. Сообщение от Аноним (146), 10-Мрт-21, 10:01 +/–

>Отлично. Опыта работы с БД у вас нет -- иначе вы бы знали, что такой фокус закончится повреждением структуры БД. Её кто-то должен восстановить. Или нет? Когда это должно произойти?
Это только если отключён журнал. Отключение журнала повысит производительность, но ненамного. Прирост не стоит риска.
>Её кто-то должен восстановить. Или нет? Когда это должно произойти?
Она сама, при перезапуске. Повреждение будет только если файлы журналов стереть.
>То есть тот факт, что вы в своём маня-мирке не видите смысла и возможности подключения нескольких клиентов к одной БД -- это проблемы БД
Подключение нескольких клиентов к SQLite есть. Но я его не использую, вместо этого врубаю монопольный доступ на запись.
>Оказывается, redis, memcached, ElasticCache не нужны -- это всё должна разруливать ОС. Пацаны то и не знали. Может, расскажешь, как ОС должна решать эти проблемы? ОС за тебя должна догадываться, что одни данные надо закэшировать, а другие нет? По какому алгоритму?
По тому же, по которому она свопит.
>Только вот расскажи, как ОС должна обрабатывать ситуацию, когда в фоне у тебя данные процессятся (то есть происходит постоянное чтение входных данных и запись выходных), в фоне же торрент качает и раздаёт, а сам ты интернеты сёрфишь (а браузер тоже кэширует кучу всего). Что должно оказаться в кэше?
А никак, когда у меня данные обрабатываются, я почти всю свободную память на машине отдаю базе под отображения. Вот эти отображения и есть кеш, который управляется ОС через менеждер памяти.

>Это я к чему -- bottleneck может быть где угодно. Узко мыслите, слишком узко
>У *тебя* один процесс.
>Я чуть выше говорил, что это только твой кейс. Из этого не следует, что других кейсов не существует.
Аргументы приняты. Я тут в основном свой случай и обсуждаю. Просто для меня возня с процессами не стоит выигрыша. В плюсовом импортере попробую поспавнить потоки.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #149

147. Сообщение от Аноним (56), 11-Мрт-21, 09:04 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #148

148. Сообщение от Ordu (ok), 11-Мрт-21, 11:03 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147

149. Сообщение от kai3341 (ok), 11-Мрт-21, 15:03 +/–

> Это только если отключён журнал. Отключение журнала повысит производительность, но ненамного. Прирост не стоит риска.
Это забавный тонкий момент. Журнал как раз позволяет восстановить структуру в автоматическом режиме. От повреждения данных журнал не защищает. А вопрос был про восстановление. Классика -- рестарт сервиса после аварии. Не менее классика -- стартует одновременно более 10 инстансов процесса -- производительности всегда мало. Далее они одновременно обнаруживают, что БД повреждена и как-то должны договориться, кто из них восстанавливает её из журнала. Вот в этом самом момента важно не воспроизвести мемас про девушку и негров. Тут возможно много yблюдских и не очень решений. Вот я и спрашивал -- какое из yблюдских и не очень решений применить здесь? Видимо, оно же будет применяться и для синхронизации транзакций при штатной работе БД. И ещё раз повторю вопрос: какое решение нужно применить для синхронизации разных рабочих процессов?
> Она сама, при перезапуске. Повреждение будет только если файлы журналов стереть.
О, тут ещё есть интересный грабледром. Попробуй штатно остановить постгрю и стереть её журналы -- повреждения и не будет, да?
PS: не делай этого.
> По тому же, по которому она свопит.
Идея почти гуд. Объяснишь, зачем тогда добавлялись флаги O_DIRECT, O_DSYNC, O_RSYNC и O_SYNC? Почему они активно используются серверами БД?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

2. Сообщение от Msk20 (?), 07-Мрт-21, 12:36	+6 +/–
Круто. По крайней мере задумка (хотя бы она). Что-то инновационное!
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #36, #76

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

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

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

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

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

14. Сообщение от Аноним (17), 07-Мрт-21, 14:03	+/–
А чего тогда не Golt? :P
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #133

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

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

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

22. Сообщение от RNZ (ok), 07-Мрт-21, 14:09	+5 +/–
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ообщить модератору
Родитель: #11 Ответы: #45

26. Сообщение от Аноним (49), 07-Мрт-21, 14:21	+1 +/–
Совершенно разные вещи. Одна из главных фич всех скриптовых языков - это REPL. А Go - компилируемый, эффективного REPLа там нет и не будет.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #17 Ответы: #29, #32, #59, #117

28. Сообщение от имятакое (?), 07-Мрт-21, 14:41	+2 +/–
стул в пепел?)))
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11

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

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

34. Сообщение от Ted (?), 07-Мрт-21, 15:35	+/–
А они есть. https://github.com/dolthub/doltpy
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12 Ответы: #39

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

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

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

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

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

42. Сообщение от Аноним (42), 07-Мрт-21, 17:14	+/–
Вот тоже интересно что-нибудь серьезней обычного bcp они сделали....
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #15

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

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

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

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

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

49. Сообщение от Аноним (49), 07-Мрт-21, 20:18	+/–
Зачем нам сын Git x MySQL, если можно внука (Git x Bitcoin) x MongoDB = OrbitDB?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #45 Ответы: #54, #77

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

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