(Not yet an Answer, but too long for a Comment.)

• 120 rows INSERTed per second. Do they arrive one row at a time? Or a whole day's worth at a time? Or something else?
• Is it a "log" file? Or CSV? Or something else? Please provide a sample.
• What kind of "time" is provided as a 36-60 character string? Please provide a sample.
• 10M rows per day --> 500GB per year. So the disk will fill up in one year? What part needs to change to handle the data you expect to receive?
• Will you be purging data after, say, 90 days? (This will solve my previous point, but needs a special schema for efficiency.)
• where field = time OR field = name is not practical. Please describe in words what the intent is. We will need to express the query some other way.
• 100^6 = 100*100*100*100*100*100 = 1 trillion. I don't think you meant that.

(Addressing most issues...)

• RAID, drive "journaling", etc, are partial solutions to the risk of data loss. They are handled at a lower level; nothing in SQL or MySQL configuration is involved with such.

• Each CSV file (of 1 to INF number of rows) is best loaded via LOAD DATA. It may be better to load it directly into the main table, or it may be better to load it into a temp table, massage the data, then copy it into the main table. (I don't have enough details to predict which is better.)

• A huge CSV file loaded directly into the main table will probably block some operations. In this case, it may be important to go through a temp table. Then, the rows could be copied into the main table in chunks, thereby minimizing impact. More on chunking: http://mysql.rjweb.org/doc.php/deletebig#deleting_in_chunks (That talks about DELETE, but can easily be adapted to the SELECT needed in your application.)

• You say that time, by itself, is Unique? Not two events can happen in the same second?

• name and time are unique? There are pros and cons about picking between INDEX and UNIQUE. UNIQUE will slow down INSERT because of the need to check for uniqueness before finishing the Insert. I don't (yet) see any benefit for UNIQUE over INDEX _for your application.

• Abnormal "time" format -- Don't plan on doing ranges or comparisons other than =. As you say, think of it as a 'hash'.

• No pruning? The data lives in this table for years? Well, what will you do about disk space if there is a 500GB/year growth rate?

• You will have

    INDEX(name),   -- (or UNIQUE(name))
    INDEX(time)    -- (or UNIQUE(time))
  

• The query you propose should be changed to this for performance. (? will become the same quoted 'hash'.)

    SELECT * FROM A  WHERE name = ?
    UNION ALL
    SELECT * FROM A  WHERE `time` = ?
  

• A may need some kind of timestamp based on the log file that it came from. I would expect some queries to get thousands of results, and the user might want only "recent" results. [OK, that conflicts your statement that name and time are unique, in which case the above Select can return only 1 or 2 rows.]

• Even if A becomes multi-terabytes, the above Select (with the above indexes) will always run in milliseconds (assuming at most 2 result rows). RAM size has essentially no impact on the speed. The disk must be big enough to hold the entire table. Furthermore, since HDD is still cheaper than SSD, it may be worth using HDD for the huge table. (The query will probably still take less than 1.0 second, regardless of configuration.)

• If you expect the table to be bigger than 32TB, we need to do something extra. That is a hard limit, but there are ways to get around it. If this will be a problem, start a new Question that focuses only on the table size (plus table schema and main Selects). The number of rows won't hit a limit, just the byte size.

• Since a new "log" arrives hourly (or whenever), the table in inherently not "up to date". That is, a Select won't find records that happened in the last hour or so. Hence, I don't worry about whether the loading of the CSV takes up to, say, an hour to run. The "chunking" I mentioned above add a little time, while avoiding blockage. So, I strongly think that the chunking is the "right" way to go based on the dataflow and other requirements.

• When is id generated? Is it ever "used"? Does include the name of the log from which it came? I am asking because: it takes space, it may be slowing things down, don't you need a "log id", maybe it could be tossed, there are better things than varchar(60) to have as the PK, etc.

may I know how to decide for what services or what type of data/application it's better to use SQL or NoSQL databases?

Use a SQL database if any combination of the following is true:

1. You have relational data
2. Your schema is under your control
3. The schema you're adhering to changes at a rate that's tolerable for you to manage

Use a NoSQL database otherwise. Specifically if your schema is ill-defined and changes more frequently than you're willing to manage.

There's not many differences in use cases otherwise. NoSQL is somewhat a subset of SQL but they compliment each other in different ways too.

What about horizontal scaling? I've read that RDBMS databases have big issues in horizontal scaling for big, rapid growing projects.

Horizontal scaling aka sharding is a little gimmicky, in my honest opinion. There's a lot of room for vertical scaling with servers these days, especially with virtualization and / or cloud services.

MongoDB is one of the most mainstream NoSQL databases that are thought of when the topic of horizontal scaling / sharding comes to mind. Many inexperienced people like to exclaim how sharding makes scaling easier, cheaper, or both. But even the developers of MongoDB claim the contrary, stating sharding is problematic, hard to manage, limiting on what queries can be ran, and they even go as far as claiming vertical scaling is just more practical and cost effective (myth #5):

Sharded clusters also make your data harder to manage, and they add some limitations to the types of queries you can conduct. Sharding is useful if you need it, but it's often cheaper and easier to simply upgrade your hardware!

In fact, that same article discusses how a minimum of 8 servers are needed to properly setup sharding with MongoDB. That's surely going to be more costly with the redundancy in paying for all of the hardware in a full system for each of the 8 servers as opposed to vertically scaling your infrastructure for a specific piece of hardware. Of course there are exception cases, but generally speaking, it's hard for me to see it being cost efficient for the average user.

But even modern SQL databases support various implementations with horizontal scaling, should one feel the need to utilize this methodology. For example, SQL Server has a feature called Availability Groups which automatically synchronizes the data from one server to the other replica servers in the same group. It even offers two modes of synchronization depending on if you prioritize performance over data consistency between servers (similar, though not exactly the same, as the idea of eventual consistency normally seen with NoSQL database synchronization in a sharded topology).

Aside from all of that, when a database is optimally architected, with efficiently designed queries, a SQL database can handle a high level of concurrency for large amounts of data. SQL Server is rated to handle tables with trillions of records. I've personally worked with tables in the 10s of billions on servers that were fairly heavily transactional (1,000s of transactions per minute), with minimal hardware (16 GB of Memory, 8 CPU cores, etc), and most queries ran in under 1 second.

Some key ideas behind this are that data at rest can be any size, and it doesn't really matter from a performance perspective (for most use cases). Proper indexing which uses a B-Tree data structure, allows for optimal searching of any achievable size of data (even by big data standards in 100 years from now). That's because B-Tree's have an O(log(n)) search time complexity. That means if your table has 1 billion rows, in the worst case, it would take log2(1 billion) = 30 to find any subset of the data. If that table grew to 1 trillion rows, log2(1 trillion) = 40 to find any subset. 30 and 40 nodes of a B-Tree takes a few milliseconds for any modern computer, even with the hardware of a cellphone, to search through.

Long story short, there are no differences from a performance perspective in what any modern SQL database is capable of vs a modern NoSQL database. Most data scale problems are usually best solvable on the software side of the equation, not really the hardware side, as most performance problems are caused by poor database design / implementation and / or poorly written code (queries).