Note: I've searched for other similar Qs here, and none of the other answered questions are even remotely similar.. With that...
I have a question about MySql tables (more precisely, on specific fields from a table- i.e. tweets or updates ).
So the question... what are the maximum amount of rows on an InnoDB table? That is if there is a significant amount of difference between the amounts MyIsam, InnoDB, and others can hold, if there isn't, then, in general. Secondly, if the table gets really large, what are the best practices for storing the data- (same one table, or split/multiple tables/dbs)?
I read that twitter gets something like 100 million tweets a day. In the same context, how would my second question apply to something like twitter?
http://dev.mysql.com/doc/refman/5.5/en/innodb-restrictions.html will allow you to calculate restrictions from your key size.
But I humbly suggest that you don't want to store info like tweets in a transactional engine with referential integrity and other features of InnoDB, and you definitely don't store them all in one table in a single DB instance. You put them into lots and lots of independent non-SQL databases that allow you to append fast, and then extract meta-information (like hashtags, RTs, etc) into a more complex database. Presentations on Twitter DB architecture are easy to google (e.g. http://www.slideshare.net/nkallen/q-con-3770885).
If you must store large amounts of data in one table, partitioning is your friend, and possibly Postgres has better support for it. A partitioned table is physically several tables that logically look as one table. You put these sub-tables (partitions) to different disks, independently run maintenance on them, etc. Also, a "star schema" with one very long table that contains only essential columns and a number of tables that store bigger but optional columns may help.