1.3, Аноним (-), 15:32, 24/02/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> TokuDB – единственное транзакционное хранилище для MySQL. Он обеспечивает
> более высокую степень сжатия данных и снижает стоимость работы в облаке,
Вроде на техническом ресурсе находимся. Более высокую степень сжатия чем кто? XtraDB не поддерживает транзакции?
| |
|
2.5, Нимано (?), 15:46, 24/02/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Вроде на техническом ресурсе находимся. Более высокую степень сжатия чем кто? XtraDB
> не поддерживает транзакции?
А что вы ожидали от перевода (1:1) очередного самопиара^W "прессрелиза"?
"press-releases/percona-server-for-mysql-57-delivers-superior-value-scalability-and-security"
delivers-superior-value-scalability-and-security"
В общем, классическое "лучше чем грузины!"
| |
|
3.10, Аноним (-), 20:26, 24/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
Сказал глупость просто чтобы сказать? Человек пишет алгоритмы сжатия => ни один алгоритм не может сжать данные сильнее человека.
| |
|
|
5.15, Аноним (-), 10:28, 25/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
Не говорите ерунды, там стандартные алгоритмы вроде lzma, lzo и т.д., нет в TokuDB никакого машинного обучения.
| |
|
|
|
|
1.4, Аноним (-), 15:42, 24/02/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> а также подходит для применения в приложениях "интернета вещей" (IoT)
Интернет вещей ничто иное как маркетинговая уловка. С нынешними тарифными тенденциями еще очень не скоро можно будет подключать вещи без удара по бюджету.
| |
|
|
3.27, Аноним (-), 17:06, 25/02/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
С wifi есть некоторые сложности - нужно пробрасывать порты, что не умеет делать большинство домохозяек, и, само собой, возникнут проблемы с коллизией портов, всем ведь 80-ый подавай. Иначе это будет не интернет вещей, а локалка вещей. И да, IPv6 еще далеко не на подходе.
| |
|
|
1.6, theDolphin (ok), 16:05, 24/02/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Интересно, они наконец пофиксили крах при восстановлении из бекапа больших таблиц? Багу уже минимум три года, и они о нём знают.
| |
1.13, Аноним (-), 22:29, 24/02/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Кто-нибудь может сказать, что лучше использовать Percona или MariaDB. И почему. Кто из них более серьезно занимается развитием своего продукта?
| |
|
2.14, nemo (??), 01:34, 25/02/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
как не странно, но oracle занимается развитием, остальные паразитируют.
| |
|
3.17, Ларри Эллисон (?), 10:46, 25/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
> как не странно, но oracle занимается развитием, остальные паразитируют.
А если вы не согласны с вышенаписанным - то встретимся в суде.
| |
|
2.16, Аноним (-), 10:44, 25/02/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Postgresql.
Как можно использовать MySQL которая не удовлетворяет SQL стандарту я не знаю.
| |
|
3.20, Ape (ok), 12:08, 25/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
Не можешь, не используй. У тебя ноги не стандартные! Как ты ходишь?
| |
|
|
5.23, Shodan (ok), 13:11, 25/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Странная аналогия. Ноги продукт длинной цепочки случайных мутаций одноклеточного организма.
> MySQL вроде продукт разумного дизайна, хотя я не уверен.
> По вашей аналогии у MySQL одна нога щупальуе, другая сменный протез куда
> можно воткнуть ершик от унитаза, или колесо, или треножник, 20+ вариантов
> https://en.wikipedia.org/wiki/Comparison_of_MySQL_database_engines
Многим это и требуется
| |
|
|
|
2.22, Pofigis (?), 12:56, 25/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
PostgreSQL, Oracle, DB2 и MS SQL на крайний случай. MySQL и SQLite для серьезных проектов использовать не рекомендуется.
| |
|
3.24, Аноним (-), 14:04, 25/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
>MySQL для серьезных проектов использовать не рекомендуется
не смешите моих цукенбергов.
>SQLite для серьезных проектов использовать не рекомендуется
только в продуктах Google имеет более 1.5 млрд пользователей.
| |
3.28, Аноним (-), 17:08, 25/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
> MySQL и SQLite для серьезных проектов использовать не рекомендуется.
Глупости..., даже полнейшая чушь! Кем это не рекомендуется?
| |
|
|
1.25, Аноним (-), 14:32, 25/02/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Смысл использовать вообще недобазу MySQL, когда есть кошерный PostgreSQL?
Сраный MySQL в 2016 году даже CHECK CONSTRAINTS до сих пор не поддерживает.
| |
|
2.29, Аноним (-), 17:10, 25/02/2016 [^] [^^] [^^^] [ответить]
| –3 +/– |
PostgreSQL - куцая MySQL, в 2016 году не имеет возможности хранить таблицы в памяти, не имеет сжатия.
| |
|
3.30, Аноним (-), 20:04, 25/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
Постгрес это куцый мускуль??? Да ты шо!
Кому нахрен нужно сжатие, когда диски стоят дешего?
Нахрен нужны таблицы в памяти, когда можно сделать RAM-диск и базу держать на нем?
Гребаная недобаза мускуль молча глотает левые данные, когда постгрес этого не даст сделать.
http://sql-info.de/mysql/gotchas.html
Мускуль - это глючная кастрированная поделка, где даже основа-основ транзакционной БД, check constraints, нихрена не реализована.
| |
|
4.31, Аноним (-), 09:14, 26/02/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Я прочувствовал истеричные нотки... Постгрес никогда не догонит мускул, ибо в самом его фундаменте заложены жесткие ограничения, а у мускула гибкость. Но есть и плюсы, всё из коробки хорошее подспорье для домохозяек, т.ч. свою нишу он держит.
| |
4.32, Аноним (-), 09:16, 26/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Кому нахрен нужно сжатие, когда диски стоят дешего?
Только если для московского буржуя
| |
|
3.33, Aleks Revo (ok), 10:51, 27/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
Постгрес может хранить таблицы где угодно, - курить маны по tablespace. При желании можно и в другой СУБД, которой не обязательно быть реляционной, да хоть в MySQL, - гуглить FDW. Но неосиляторы, выбравшие MySQL из-за низкого порога вхождения, будут хорохориться и выдавать оправдания одно нелепее другого.
| |
|
|
|