Ну и заодно чего нить нового изучить, не постгресами же едиными.

не скажу про болт =) не знаю его. Лучше поддержать переписывание sqlite на Go =)

+ Вроде что-то такое было, но в зачаточном состоянии

https://github.com/cznic/ql/blob/master/README.md

https://github.com/cznic/ql/blob/master/README.md

Вооот

Т.е. если вот смотреть на какие нибудь редисы и монги , то им нужен сервер же, поставить настроить, то сё. А хочется как sqlite , файлик и вперед. Даже конкуретный доступ не парит, будет один процесс. Но вот нужно выбирать по внутренностям документов. Можете что нибудь посоветовать?

Т.е. если вот смотреть на какие нибудь редисы и монги , то им нужен сервер же, поставить настроить, то сё. А хочется как sqlite , файлик и вперед. Даже конкуретный доступ не парит, будет один процесс. Но вот нужно выбирать по внутренностям документов. Можете что нибудь посоветовать?

Выше скинул - qldb

Выше скинул - qldb

Я видел спасибо. Но оно опять relation, мне за годы надоело, хочу документное что то. Понимаю всю так сказать эфемерность различий, и можент вообще непонятного хочу, но вот хочется новизны. Какой то inprocess монги скорее, чем sqlite

я бы хотел заметить, что это очень странное желание

"я не хочу умное и гибкое, я хочу тупое и деревянное, но новое"

в многонодовой системе это тупое и деревянное имеет смысл - эта тупость и деревянность позволяет строить кластерные базы

но встраиваемое?..

Я видел спасибо. Но оно опять relation, мне за годы надоело, хочу документное что то. Понимаю всю так сказать эфемерность различий, и можент вообще непонятного хочу, но вот хочется новизны. Какой то inprocess монги скорее, чем sqlite

Можно вот это попробовать https://github.com/tidwall/buntdb Но вообще, если цель не в том, чтобы писать продукт, а хочется поизвращаться, то почему бы самому не написать простенькую СУБД поверх болта? С индексацией и репликами?ъ

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

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

и я на перле пишу, чо мне

Можно вот это попробовать https://github.com/tidwall/buntdb Но вообще, если цель не в том, чтобы писать продукт, а хочется поизвращаться, то почему бы самому не написать простенькую СУБД поверх болта? С индексацией и репликами?ъ

Во, вроде интереснее, custom index, спасибо

Ещё вотъ, но я не пробовал и оно in-memory https://github.com/hashicorp/go-memdb

и я на перле пишу, чо мне

да ниче :) просто у нас тут язык со строгой статической типизацией, и понятно - зачем он такой. в этом смысле db тоже хорошо иметь со строгой статической, да еще и с другими средствами контроля целостности, вроде foreign keys

Помойму первое, подходит db.CreateIndex("age", "*", buntdb.IndexJSON("age")) , покрывает 90% потребностей моих

да ниче :) просто у нас тут язык со строгой статической типизацией, и понятно - зачем он такой. в этом смысле db тоже хорошо иметь со строгой статической, да еще и с другими средствами контроля целостности, вроде foreign keys

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

хипстеры будут гореть в аду

некоторые - прижизненно

особенно те, которые schemaless базы тянут в прод

не в смысле, что боженька накажет

а в смысле, что это реально ад, поддерживать эту всю херню

Тем лучше обжечься на мелком проекте где я один девелопер. Будут мысли и аргументы в последующем. Но вообще я верю что обойдется.

а на мелком ты можешь и не обжечься

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

в многонодовой системе это тупое и деревянное имеет смысл - эта тупость и деревянность позволяет строить кластерные базы

С другой стороны, много ли мы знаем хороших кластерных решений поверх этой тупости. Примерно одно

два

аэроспайк и кассандра

Ok. Два

говорят, последняя монга перестала терять данные

и, говорят, пора смотреть на тарантул

говорят, последняя монга перестала терять данные

А у нее под капотом kv?

ага

и, говорят, пора смотреть на тарантул

А у него под капотом kv?

да

но есть еще вопрос вторичных индексов

и тут они все сосут разнообразно, но все с заглотом

Да светится, Google, имя твоё Да придёт царствие NewSQL и на земле и на небеси Смузи наш насущный дай нам днесь И подверни джинсы наши Как подворачиваем мы сыновьям нашим И прости нам eventual consistency Как мы прощаем остальным базам И не введи нас в искушение, но избави нас от Oracle Раминь

извините

нет

ну а монга то?

что - монга?

монго это плохо

Без монги тяжело штанишки подворачивать

Без монги тяжело штанишки подворачивать

и масштабировать

мы с монгой, но без подвёрнутых штанишек, что не так?

Вы это чем-то компенсируете

Смузи мб? Признавайтесь!

вэйп компенсирует подворот?

Определенно

но у нас вэйпят лишь двое

а вот скажите - почему монга?

почему именно такой выбор?

онаняшная

онаняшная

если это все - я не верю про подвороты и вейпы. просто вы шифруетесь..

нам нужна была носкьюл база, вот и всё

и что?

кроме монги вы не знали ни одной?

и взяли монгу

предложи что лучше

под какую задачу?

а вот скажите - почему монга?

Она популярна ис большим комьюнити, проста в настройке Можно наговнякать, вообще не думая

ну вот это подворотно-вейперская аргументация

ну вот это подворотно-вейперская аргументация

зато правда

нам нужна была носкьюл база, вот и всё

что ттакое "ноускьюл база" и чем она лучше "скьюл базы"?

ну там нет sql

ну там нет sql

Так это плохо же

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

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

именно что

Там где взяли sqlite можно было обойтись grep

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

как бы у sql и nosql баз немного разная область применения

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

под какую задачу?

изменяющаяся схема без мучений с миграциями

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

про тебя мы поняли. скорбим.

Я к тому что какая аргументация бывает

Так это плохо же

NO-SQL - not only sql Вообще правильнее было бы назвать нереляционные базы данных. РСУБД - данные организованы в таблички. НеРСУБД - данные организованы по-разному (начиная от kv, заканчивая всякими сложными конструкциями)

изменяющаяся схема без мучений с миграциями

а зачем это нужно?

NO-SQL - not only sql Вообще правильнее было бы назвать нереляционные базы данных. РСУБД - данные организованы в таблички. НеРСУБД - данные организованы по-разному (начиная от kv, заканчивая всякими сложными конструкциями)

Это если на пальцах

Я ещё и не ушел собственно, просто так сказать играюсь в хипстера

а зачем это нужно?

специфика проекта

дальше нда

так я и спрашиваю - в чем она, эта специфика?

NO-SQL - not only sql Вообще правильнее было бы назвать нереляционные базы данных. РСУБД - данные организованы в таблички. НеРСУБД - данные организованы по-разному (начиная от kv, заканчивая всякими сложными конструкциями)

я знаю :)

как бы у sql и nosql баз немного разная область применения

В идеале - да. На практике - зайди в нодовский чатик и спроси, какую СУБД взять. 80% тебе сразу скажут "бери монгу, гы", даже не поинтересовавшись задачей. Так и живём

дальше нда

Это значит не знаю.

Это значит не знаю.

хранилище со схемой задаваемой и изменяемой пользователем схемой

Ну это то что меня толкает в ваши монги

Хотя, признаюсь честно. я не умею их готовить то

хранилище со схемой задаваемой и изменяемой пользователем схемой

"хуяк хуяк и деплой"

вопросы прямо чувствую ламерские у меня возникают

вопросы прямо чувствую ламерские у меня возникают

meh Как что-то плохое

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

Хотя, признаюсь честно. я не умею их готовить то

у них есть замечательный курс

мне б таки не монгу, а что то проще, key-> document такое вот, но с индексами.

хранилище со схемой задаваемой и изменяемой пользователем схемой

пока не понимаю, зачем бы это могло быть нужно

Или там общий курс, про идеи?