221–230 of 246 posts
Earlier quoted context omitted.
Hey, just took a look at soundslice, looks super nice. FYI, it doesn't look your payment modal works on smaller browser windows: https://www.monosnap.com/image/UvJbxMQEwkzqLH5btNJ7a9G6Q ... no visible pay button, and the modal itself scrolls when you scroll the page.
Thanks very much -- I've just done a band-aid solution and moved the payment modal up, but we'll get a better solution up soon. Much appreciated!
Earlier quoted context omitted.
How is this not true? It absolutely IS vendor lock-in, just in a slightly less sinister form. If you add 5 services & then to switch hosts it's not another git push. You have to re-configure each of the services. If you'd done this yourself all along & made machine images it would have been less convenient at the time, but probably cheaper & a good learning experience. There are many other hosting platforms that offe…
> Plus there's a lot of value in learning how to work with machine images that goes way beyond hosting a web app. Every minute I spend doing that is a minute I spend not doing things I enjoy. YMMV though.
I prefer the Amazon model because you can stick these all on one server & as long as CPU isn't pegged at 100% you're good. I agree tho I'd rather not spend the time figuring it out. For now I only use it for RDS & for services not available on Heroku (some Adobe streaming server stuff).
I've heard about PostgreSQL and know that HN community raves about it, but am currently using RDS with MySQL. Does it make sense to migrate to PostgreSQL, I don't have a lot of data as I'm in the early stage? What are the primary advantages that PostgreSQL provides over MySQL? Any advise/pointers is appreciated.
Postgres actually cares about your data. Perhaps you mistakenly insert "2013-10-32" into a date column. MySQL will silently convert this to "0000-00-00" (!!). Postgres will raise an error. Perhaps you make an error in a transaction. MySQL lets you keep doing subsequent things in the transaction. Postgres treats the transaction as invalid and forces you to start over. Perhaps you want to add a column to a table that h…
> Perhaps you mistakenly insert "2013-10-32" into a date column.
Only with ALLOW_INVALID_DATES sql mode set. As of 5.0.2, the server requires by default that month and day values be legal, and not merely in the range 1 to 12 and 1 to 31.[1]
> Perhaps you make an error in a transaction. MySQL lets you keep doing subsequent things in the transaction.
If you care about transactions you should have STRICT_TRANS_TABLES on.[2]
[1] - http://dev.mysql.com/doc/refman/5.6/en/server-sql-mode.html#...
[2] - http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html#...
Earlier quoted context omitted.
> Less than 1% of 1% of mysql users are using replication. If you count all the crappy shared hosts, XAMPP local installs, and hobbyists setting up their own little VPSes, perhaps. Using a single, unreplicated database instance in production for anything serious is bizarre. Failed hardware is hardly unheard of.
>Using a single, unreplicated database instance in production for anything serious is bizarre It is incredibly common. Go check out a thousand businesses running mysql, you'll be able to count the ones using replication on your fingers. >Failed hardware is hardly unheard of. You don't need to use mysql replication to deal with that. Even the crappiest low end SAN storage devices do it vastly better than mysql does, w…
Replication can be done off-site so you at most lose a couple of seconds worth of data. I do not know anything about MySQL's replciation but my trust in PostgreSQL's is very high.
Earlier quoted context omitted.
I don't know if I would really say Postgres won. Among people who care about databases, Postgres has always been the more popular of the big two free databases. Postgres was actually dedicated to being a good relational database, whereas MySQL in its earlier days was willing to cut corners to the point where it wasn't even ACID in most common configurations. But MySQL was faster (because, again, cutting corners) and…
don't forget postgres didn't officially support replication until late 2010, which was a total non-starter for many/most production uses
Earlier quoted context omitted.
Yeah I was disappointed to see this.. Can you configure pgpool externally to talk to the replicas or are those multi-az instances a black box? I've never used RDS before so I'm curious as to how much flexibility is afforded.
Unfortunately, no. Amazon RDS instances don't provide console access and are essentially black boxes.
Earlier quoted context omitted.
Hey at least it throws a warning on the bogus date conversion (MySQL warnings should almost always be treated as fatal errors). The thing that kills me with MySQL (technically it's with InnoDB-based storage enginges in MySQL) are the subtle quirks. Like the thing where it insists on writing temporary tables to disk if you do a query that selects TEXT or BLOB fields. Even if they could have easily fit in memory, it's…
I run a small Wordpress network. MySQL's insistence on going to disk for joins on tables with a TEXT field (even if the query doesn't touch those fields ) is probably the major performance bottleneck.
http://dev.mysql.com/doc/refman/5.7/en/internal-temporary-ta...
I'm not sure what the status of TEXT-fields are in mariadb:
https://mariadb.com/kb/en/optimizing-string-and-character-fi...
Will anyone please explain the tactical reasons why PostgreSQL won? It's pretty obvious it has. I've basically ignored the database wars for a few years, so it's kind of interesting to see that everyone's using PostgreSQL now.
I never really understood why you'd want to use a separate dbms if it couldn't do proper constraints, triggers, transactions and materialized views for you -- then it starts to feel like a lot of wasted effort.
So for many of the use-cases where MySQL might have been appropriate, we now have sqlite, mongodb, memcache/redis and a few others.
Personally I don't really see any reasonable use-cases for mongodb, just as I didn't see many reasonable use-cases for mysql -- not that you couldn't build stuff on top of it, just that it wasn't a very good idea.
Earlier quoted context omitted.
From a very quick glance at the small end the Amazon options are a little more than half the price (Ireland single AZ instance pricing and even less reserved) but multi-AZ options are probably very similar. I don't actually know whether Heroku can failover across an AZ failure.
> From a very quick glance at the small end the Amazon options are a little more than half the price (Ireland single AZ instance pricing and even less reserved) but multi-AZ options are probably very similar. Did you add disk? People seldom do, I can attest it's a big part of the bill... > I don't actually know whether Heroku can failover across an AZ failure. "Followers" have preferred another AZ for quite some time…
So pricing wise both double if you go multi-AZ.
I didn't claim to have done a detailed price comparison but a quick look at the small sizes which are currently the ones relevant to me.
Earlier quoted context omitted.
> From a very quick glance at the small end the Amazon options are a little more than half the price (Ireland single AZ instance pricing and even less reserved) but multi-AZ options are probably very similar. Did you add disk? People seldom do, I can attest it's a big part of the bill... > I don't actually know whether Heroku can failover across an AZ failure. "Followers" have preferred another AZ for quite some time…
No, I didn't take storage or IOPs into account but you do get more memory and the flexibility if the Heroku options don't fit you. So pricing wise both double if you go multi-AZ. I didn't claim to have done a detailed price comparison but a quick look at the small sizes which are currently the ones relevant to me.
No doubt about that. To date, Heroku's product model has preference for fewer, but common choices rather than more flexibility. Heroku's staff sees fit to give in sometimes, but coarsely speaking, that's pretty much how it goes.