@gogolang

Страница 1545 из 1630
Max
12.10.2018
16:48:36
если у вас в памяти 3 терабайта данных, это не значит что надо просканировать все 3 тарабайта сборщику. Сканировать приходится обычно в разы меньше, в очень большие разы, сборщик мусора анализирует не значения.
возьмем например объект у которого 20 int64 полей то для 3тб получится 20млд объектов и если сильно оптимистически посчитать что процессор успевает просканивовать один объект за один такт то для 2ггц процессора получится 10 секунд, в реальности в разы больше (плюс кроме прохода по объектам надо еще выяснить те которые остались чтобы удалить), даже если и можно компенсировать это многоядерностью все равно получается порядок на десятки секунд что точно не вариант если gc не умеет делать сборку мусора инкрементально и будет приостанавливать обработку запросов на 10 секунд

Google
Alexander
12.10.2018
16:51:32
Эээ
в структуру запихни все полученные из функции данные и всё

структуры изоморфны кортежам
с точностью до названий полей

Илья
12.10.2018
16:54:10
обычно этого добиваются оффлайн очисткой, то есть удаление - это не удаление, а очистка идет в фоне

anatolii
12.10.2018
16:54:50
Вы же понимате что мусорщик не сканирует регулярно сканирует все все, у него есть алгоритмы определенные + он не удаляет мусор, если нагрузка сейчас высока, он ждет в допустимых пределах, паузы делает итд

Это не тупой фореч по таймауту

Max
12.10.2018
16:55:05
И часто вы храните только инт? строк тонна будет
так а строки это просто ссылка на другой объект которая кодируется в виде int64, то есть под интами я посчитал не просто числа а и ссылки, плюс есть еще массивы где объекты друг за другом находятся и это тоже увеличивает процент памяти который надо сканировать

Илья
12.10.2018
16:55:14
и там gc будет прерывать много раз, но на очень короткие промежутки времени, но это не скажется на клиентой работе

Alexander
12.10.2018
16:55:19
Народ подскажите пожалуйста а на go можно написать in-memory базу данных? У меня почему есть уверенность что все языки со сборщиком мусора не подходят для этого и go как язык с gc соотвественно тоже но хотелось бы уточнить. Для in-memory базы даннных важны минимальные задержки при сборке мусора а точнее даже чтобы эти задержки не зависели от количества объектов в памяти. Сейчас серверы могут иметь до 3 терабайт оперативной памяти (и еще больше терабайт если используется свап на быстрых nvme ssd дисках) и поскольку принцип работы сборщика мусора заключается в том чтобы просканировать все достижимые объекты с корня и очистить все остальные то только для сканирования 3 терабайт объектов потребуется несколько десятков секунд. Поэтому сразу возникает вопрос - умеет ли сборщик мусора в go работать инкрементально а не по принципу "stop the world" и насколько большие расходы в целом на gc в зависимости от количества объектов?
Можно написать её даже на питоне, но не нужно. У го 1) гц, 2) очень плохой оптимизатор, 3) совершенно не нужный для этой задачи рантайм

Как?
a, b, c := pook() s := MyStruct{a, b, c}

anatolii
12.10.2018
16:56:31
так а строки это просто ссылка на другой объект которая кодируется в виде int64, то есть под интами я посчитал не просто числа а и ссылки, плюс есть еще массивы где объекты друг за другом находятся и это тоже увеличивает процент памяти который надо сканировать
Если у меня обьект с 20 полями стринга, в которых лежит википедия, то на всю мапять у меня будет всего пара обтектов, которые за наносекунды будут обрабатываться. Не надо спорить о синтетике, выше вам кинули ссылку на бд на го, возьмите и потестите, она опенсорсная и бесплатная

Google
Tishka17
12.10.2018
16:56:48
a, b, c := pook() s := MyStruct{a, b, c}
а без промежуточных переменных?

Alexander
12.10.2018
16:56:59
казалось бы, причем тут гц и оптимизатор
если нам не нужно, чтобы in-memory бд была быстрая, то почему бы не написать её на питоне?

Alexander
12.10.2018
16:58:52
потому что есть GIL? define "быстрая"
1) высокая скорость ответа 2) низкое потребление ресурсов 3) способность обрабатывать большое количество клиентов

Илья
12.10.2018
16:59:20
почему там не мешает обозначенные выше аргументы?

Alexander
12.10.2018
16:59:57
Зачем вообще самому писать imdb? Если нужна для проекта - возьмите готовую, если нужна для курсача - пишите на чем хотите. Если вдруг существующие решения вам не подходят и прямо надо написать своё, у меня для вас плохие новости

Alexander
12.10.2018
17:02:40
а зачем нужна медленная in-memory db?
Как вариант - я написал. Для учебного проекта. И там правда на чем угодно и неважно какая скорость

Vladimir
12.10.2018
17:04:44
Народ подскажите пожалуйста а на go можно написать in-memory базу данных? У меня почему есть уверенность что все языки со сборщиком мусора не подходят для этого и go как язык с gc соотвественно тоже но хотелось бы уточнить. Для in-memory базы даннных важны минимальные задержки при сборке мусора а точнее даже чтобы эти задержки не зависели от количества объектов в памяти. Сейчас серверы могут иметь до 3 терабайт оперативной памяти (и еще больше терабайт если используется свап на быстрых nvme ssd дисках) и поскольку принцип работы сборщика мусора заключается в том чтобы просканировать все достижимые объекты с корня и очистить все остальные то только для сканирования 3 терабайт объектов потребуется несколько десятков секунд. Поэтому сразу возникает вопрос - умеет ли сборщик мусора в go работать инкрементально а не по принципу "stop the world" и насколько большие расходы в целом на gc в зависимости от количества объектов?
До Go 1.11 кажется был лимит на 512ГБ рам на Гошный процесс. А так - ну есть базочки ж на Гошечке в том числе in-memory

Alexander
12.10.2018
17:05:04
http://kokizzu.blogspot.com/2017/05/postgresql-vs-cockroachdb-vs-scylladb.html

Илья
12.10.2018
17:05:38
ну так парни уже завезли версию два, и там норм

Alexander
12.10.2018
17:05:40
первый бенчмарк в гугле > seriously slow on every part of this benchmark

Илья
12.10.2018
17:06:18
я это к тому, что писать на го можно, и оно вполне работает, комьюнити есть, зачем то люди пользуют

Alexander
12.10.2018
17:06:21
при том что первая версия в 2 раза медленнее постгреса в лучшем случае

Илья
12.10.2018
17:07:02
+ 1/4 прибавки
вообще чуваки пишут про 70%, но наверное, вам стоит это проверить, а то очень голословные утвержденияя

Roman
12.10.2018
17:07:35
Народ подскажите пожалуйста а на go можно написать in-memory базу данных? У меня почему есть уверенность что все языки со сборщиком мусора не подходят для этого и go как язык с gc соотвественно тоже но хотелось бы уточнить. Для in-memory базы даннных важны минимальные задержки при сборке мусора а точнее даже чтобы эти задержки не зависели от количества объектов в памяти. Сейчас серверы могут иметь до 3 терабайт оперативной памяти (и еще больше терабайт если используется свап на быстрых nvme ssd дисках) и поскольку принцип работы сборщика мусора заключается в том чтобы просканировать все достижимые объекты с корня и очистить все остальные то только для сканирования 3 терабайт объектов потребуется несколько десятков секунд. Поэтому сразу возникает вопрос - умеет ли сборщик мусора в go работать инкрементально а не по принципу "stop the world" и насколько большие расходы в целом на gc в зависимости от количества объектов?
можно, но посить её думаю лучше на Rust) Go это не про systems programming, скорее про application programming база данных это типичный пример systems programming'a *можно начинать закидывать меня помидорами*

Илья
12.10.2018
17:08:03
при том что первая версия в 2 раза медленнее постгреса в лучшем случае
вопрос изначально был - можно ли писать - я показал живой проект, как доказательство того, что можно, а у вас опять стул подгорает

Google
Daniel
12.10.2018
17:08:22
Народ подскажите пожалуйста а на go можно написать in-memory базу данных? У меня почему есть уверенность что все языки со сборщиком мусора не подходят для этого и go как язык с gc соотвественно тоже но хотелось бы уточнить. Для in-memory базы даннных важны минимальные задержки при сборке мусора а точнее даже чтобы эти задержки не зависели от количества объектов в памяти. Сейчас серверы могут иметь до 3 терабайт оперативной памяти (и еще больше терабайт если используется свап на быстрых nvme ssd дисках) и поскольку принцип работы сборщика мусора заключается в том чтобы просканировать все достижимые объекты с корня и очистить все остальные то только для сканирования 3 терабайт объектов потребуется несколько десятков секунд. Поэтому сразу возникает вопрос - умеет ли сборщик мусора в go работать инкрементально а не по принципу "stop the world" и насколько большие расходы в целом на gc в зависимости от количества объектов?
Проблемы есть, и тот же Убер в них влетел и о них много рассказывает

Alexander
12.10.2018
17:09:29
вопрос изначально был - можно ли писать - я показал живой проект, как доказательство того, что можно, а у вас опять стул подгорает
как может не подгорать стул, когда живешь в мире, где гуи приложения пишут на электроне, а перфоманс и латенси критикал софт на го?

Александр
12.10.2018
17:09:31
Проблемы есть, и тот же Убер в них влетел и о них много рассказывает
а если работу с памятью написать на С и кросс компиляцией бахнуть?

даже игры

Илья
12.10.2018
17:11:16
как может не подгорать стул, когда живешь в мире, где гуи приложения пишут на электроне, а перфоманс и латенси критикал софт на го?
вот смотрите - https://www.techempower.com/benchmarks/ , на первом месте С, потом С++, потом Джава, потом голанг (Фастхттп)

живут же люди!

Roman
12.10.2018
17:12:13
а если работу с памятью написать на С и кросс компиляцией бахнуть?
найн найн найн найн найн!!! 1. база данных это типичный systems programming (software for software) 2. C это допотопная технология, писать на ней новую бд это застрелить проект до его зарождения. 3. Rust это новый язык со всеми шнягами и безопасностью из-коробки и незначительно медленее C 4. Go тут, ещё раз, увы не подходит

Александр
12.10.2018
17:13:13
>Rust это новый язык со всеми шнягами и безопасностью из-коробки и незначительно медленее C вы в 1С не работаете? формулировки прямо как из брашуры по битриксу

Roman
12.10.2018
17:14:49
>Rust это новый язык со всеми шнягами и безопасностью из-коробки и незначительно медленее C вы в 1С не работаете? формулировки прямо как из брашуры по битриксу
я против C/C++ в новых проектах, но единственная серьёзная альтернатива этим языкам это Rust, не Go, Go он про другое

anatolii
12.10.2018
17:15:13
как может не подгорать стул, когда живешь в мире, где гуи приложения пишут на электроне, а перфоманс и латенси критикал софт на го?
Там, судя по описанию, упор ставился на надежную масштабируемость а не на супер скорость

Subbotin
12.10.2018
17:16:18
Roman
12.10.2018
17:16:42
ну часть плюсовых то проектов как раз нормально на го переписываются.
эта часть всегда связанна с Application Programming'ом. Не systems

Vladimir
12.10.2018
17:17:32
@Romshark в моем мире "systems programming" это ОС, драйвера и компания, близко к железу. А вот база данных - нифига. А с вашим определением, простите, grep или cat это systems программинг

eugene
12.10.2018
17:17:40
ну часть плюсовых то проектов как раз нормально на го переписываются.
так можно на современном C++ переписать, разве не лучше?

Google
Илья
12.10.2018
17:17:44
го обогнал го?

Roman
12.10.2018
17:18:37
тем не менее rocksdb(c++), tarantool(c/c++), spanner(c++)
потому-что C++ никто не отменял. Специалистов C++ придостаточно, в то время как Rust практически только-только зародился.. но как бывший плюсер я даже в C++2a сомневаюсь. Слишком уж нагромоздили его всякой всяченой, отличнейший инструмент для стрельбы по ногам

так можно на современном C++ переписать, разве не лучше?
нет, не лучше. Compile-time безопасности как у Rust там не будет (без спец. анализаторов, которые нужно отдельно настраивать и возможно даже покупать потому-что статически анализировать C++ код это то ещё удовольствие)

segfault'ы и data race'ы гарантированы)

Vladimir
12.10.2018
17:20:10
тем не менее rocksdb(c++), tarantool(c/c++), spanner(c++)
Спаннер все же проприетарный, а одна из двух баз которая им вдохновляется на го написана. Нынче всякая шняга вокруг мониторинга тоже на го пишется, включая базы

Roman
12.10.2018
17:20:12
а мы тут про базу данных говорим, где надёжность один из приоритетов

Александр
12.10.2018
17:20:14
народ наро

А НИЧЕГО ЧТО КАНАЛ ПО GO?

Vladimir
12.10.2018
17:20:22
Не надо быть таким категоричным

Александр
12.10.2018
17:20:31
уберите секту свидетелей руста плис

Vladimir
12.10.2018
17:20:37
Вполне есть задачи где Гц не так сильно и мешает

Subbotin
12.10.2018
17:20:40
тем не менее rocksdb(c++), tarantool(c/c++), spanner(c++)
ну так все эти проекты начали писать до выхода раста в стабильный релиз

Aleksandr
12.10.2018
17:20:41
А НИЧЕГО ЧТО КАНАЛ ПО GO?
так про го и говорят по сравнению с

Roman
12.10.2018
17:20:44
А НИЧЕГО ЧТО КАНАЛ ПО GO?
так и вопрос был про Go изначально, пришлось объяснять что он не подходит для решения данной задачи

Alexander
12.10.2018
17:20:53
го обогнал го?
фастхттп почти в 4 раза быстрее среднестатистического решения на го, при этом чаще всего используются среднестатистические решения на го, чтобы не огрести проблем

Илья
12.10.2018
17:21:05
Google
Alexander
12.10.2018
17:21:45
да и о каком перфомансе можно говорить в языке без генериков, алгебраических типов, но зато с интерфейсами и повальной рантайм рефлексией

Илья
12.10.2018
17:21:48
на русте тоже не все в actix сидят

Vladimir
12.10.2018
17:21:57
ну так все эти проекты начали писать до выхода раста в стабильный релиз
Раст слишком молодой и ещё на многих производит ощущение "выглядит клёво, но в жизни на этом писать не буду"

Илья
12.10.2018
17:22:01
баз данных?
мы вроде про них говорим, да

Subbotin
12.10.2018
17:22:19
мы вроде про них говорим, да
https://github.com/rust-unofficial/awesome-rust#database

Alexander
12.10.2018
17:22:38
на русте тоже не все в actix сидят
те кто в актикс не сидят обычно берут что-то более низкоуровневое и сами оптимизируют:)

Илья
12.10.2018
17:23:00
https://github.com/rust-unofficial/awesome-rust#database
что из этих 4х живое и используется в проде?

Vladimir
12.10.2018
17:23:02
вопрос времени
и время покажет найдет ли раст себе нишу

Roman
12.10.2018
17:23:07
с Go всё проще потому-что язык простой и не про системное программирование. Был бы Go более low level то он бы тоже так не взлетел, конкурировать с C++ очень сложно

Vladimir
12.10.2018
17:23:09
или через 5 лет про него никто не вспомнит

Илья
12.10.2018
17:23:27
Prerequisites Rust nightly.

и не делает так

eugene
12.10.2018
17:23:39
и время покажет найдет ли раст себе нишу
?вроде уже показывает: https://www.rust-lang.org/en-US/friends.html

Subbotin
12.10.2018
17:24:35
что из этих 4х живое и используется в проде?
https://github.com/tikv/tikv ну вот явно живое. и кто-нибудь наверняка использует. это не говоря о парити

Страница 1545 из 1630