HarrisonFisk

8 ms·

31.
by HarrisonFisk 14y ago
The primary settings are: sync_binlog=1 innodb_flush_log_at_trx_commit=1 (which is default, but we add it to our configs since we run with =2 on the slaves since they don't need full durability) We do use some performance related settings
32.
by HarrisonFisk 14y ago
Regarding #2, we do normally run MySQL with full transactional durability at Facebook. We have for a very long time (several years at least). For example, here is a FB note regarding our enhancing performance under full durability in MySQ
33.
by HarrisonFisk 14y ago
Any chance you could publish full info on the benchmarks? For example, where can we find your configurations for the MySQL vs. MemSQL benchmark you show in your video? Or how big the dataset was, etc...?
34.
by HarrisonFisk 14y ago
The MySQL optimizer will actually notice and remove the outer join aspect automatically. So I have often done this out of pure laziness if I start with an outer join, but really end up needing an inner join.
35.
by HarrisonFisk 15y ago
HPHP has a built in multi-threaded webserver.
36.
by HarrisonFisk 15y ago
Quora question about that: http://www.quora.com/How-does-Facebook-implement-feature-swi...
37.
by HarrisonFisk 15y ago
It's a bit funny that you use Facebook as an example since they use sharded MySQL as their primary data store.
38.
by HarrisonFisk 15y ago
It is more suited for realtime transaction processing type activity, not for big data type analytics. NDB was originally created by and for telecoms. So very high write/read rates with very fast response times and very high availability re
39.
by HarrisonFisk 15y ago
NDB originally only had a NoSQL interface called NDB API. NDB API is a bit complex and when MySQL acquired them, they added the SQL layer on top of it to make it easier for developers to use it. This release adds an additional memcache api
40.
by HarrisonFisk 15y ago
For point #3, NDB has supported on disk non-indexed attributes for a while now (2-3 years?). So you just need to be able to fit indexes in memory which is a much smaller dataset, but still limiting. I'm sure for the benchmark it was all in
41.
by HarrisonFisk 15y ago
There is a big difference with regards to PostgreSQL and InnoDB when you have an indexed COUNT(*) clause. MySQL can do index only queries, whereas PG currently can not (it is part of the next release iirc). This can often result in a fract
42.
by HarrisonFisk 15y ago
You need to make sure all of your DB changes are backwards compatible. For example, adding new tables, adding columns (with defaults), and adding indexes can all be done without breaking existing code. The code does need to do the proper
43.
by HarrisonFisk 15y ago
PostgreSQL schemas are very similar to MySQL databases in functionality. In fact, in MySQL you can use SCHEMA in all places you can use the term database, ie. CREATE SCHEMA foo; instead of CREATE DATABASE foo;
44.
by HarrisonFisk 15y ago
There are a number of benefits: 1. InnoDB has certain optimizations that PG lacks which can make a big performance difference at the high end: index-only queries, insert buffer (or change buffer in MySQL 5.5+), clustered index 2. Lightwe
45.
by HarrisonFisk 15y ago
All content on timeline follows the same privacy settings as the object has. So if you have been posting things as Friends only, all of the content will also be Friends only. If you have been posting Public updates, then it will also be P
46.
by HarrisonFisk 15y ago
You can choose what is shown or hidden. There are initial recommendations, but you have 100% control over what is shown, highlighted or hidden.
47.
by HarrisonFisk 15y ago
I don't think the latter SQL would be significantly faster assuming the appropriate index on created_at. The database can read the last 10 via the index directly and they would all most likely be on the same index page. Assuming any sort o
48.
by HarrisonFisk 15y ago
Facebook uses MySQL as it's primary data store, with some hbase, cassandra, and other more minor usage storage solutions in various places.
49.
by HarrisonFisk 15y ago
MongoDB is being used for historical archiving, not for the live site itself. The big reason being that changing table schemas for very large sets of old data is painful with MySQL. So the 2 billion number would be any ad/listing older th
50.
by HarrisonFisk 16y ago
The problem with the solutions you mentioned is that it requires double provisioning hardware. When you have just a few MySQL servers, buying a few extra isn't a big deal. When you have X,000 MySQL servers, buying X,000 * 2 is a huge deal
51.
by HarrisonFisk 16y ago
You can use DRBD on linux to do synchronous replication of any file system since it works on the block level.
52.
by HarrisonFisk 16y ago
You can actually use LVM on a live InnoDB instance as long as both the logs and tablespace reside on the same volume. There is no locking required. We actually used LVM at Facebook for MySQL backups for a while, however as you stated it re