71–80 of 183 posts
> When someone clicks a link to a Wix site... That server has to resolve the requested site from the site address by performing a key/value lookup URL to a site. So Wix uses MySQL to resolve site routes internally? Is this the best way to do it? Would it be possible to use internal domain names and rely on DNS to resolve everything?
So much to disagree with here ... > Locks limit access to the table, so on a high throughput use case it may limit our performance. Then use a proper database that implements MVCC. > Do not use transactions, which introduce locks. Instead, use applicative transactions. Or just use a database that handle transactions more efficiently. > `site_id` varchar(50) NOT NULL, Why varchar(50)? UUIDs are 16-bytes. The best way…
To be fair, this article is about using MySQL as a NoSQL storage and so all of this advice is geared towards that use-case. I'd kill for so much traffic that any of this would be necessary as opposed to any RDBMS best-practices. I do agree that UUIDs should be stored differently -- the use of varchar rather than a fixed length type for a primary key will hurt performance.
I would love to switch to native UUID someday though.
I thought nosql movement was about distributed systems, cap and all that. What does this "active-active-active" even mean? No consistency and no availability guaranties I presume?
Earlier quoted context omitted.
MySQL is faster than pg, you should ask why Facebook is running the largest MySQL shop.
Maybe because they started with a tiny LAMP system in 2004 and got stuck there to the point they invested considerable resources to write their own PHP interpreter and optimize MySQL. From https://www.percona.com/blog/2014/03/27/a-conversation-with-... "we had the MySQL engineering talent we needed to work with the Oracle team to get 5.6 ready for production at our scale." "We all worked hard to adapt 5.6 to our scal…
Earlier quoted context omitted.
To be fair, this article is about using MySQL as a NoSQL storage and so all of this advice is geared towards that use-case. I'd kill for so much traffic that any of this would be necessary as opposed to any RDBMS best-practices. I do agree that UUIDs should be stored differently -- the use of varchar rather than a fixed length type for a primary key will hurt performance.
We use varchar for UUID (on postgres) which surprisingly hasn't been that terribly performance wise. And yes we do use varchar(36) although on postgres it doesn't really matter because I think almost all varchars are text. I would love to switch to native UUID someday though.
ALTER TABLE my_table ALTER COLUMN my_uuid TYPE uuid USING uuid::uuid;
I don't have experience with MongoDb and such, but I've always asked myself why someone wouldn't use Solr as a distributed NoSQL database... Am I wrong or, with Solr, you get that key/value scalable storage AND you get advanced search features as an extra?
Why would I want to use MongoDb instead of Solr? What killer feature Solr doesn't have?