*Note this answer starts out in regards to the default isolation level which is what OP originally asked about, but then goes into the actual isolation level he was curious about.
In general DML queries do cause locks on rows and Tables which will affect SELECT performance, especially in the READ COMMITTED isolation level. It depends on the specific DML operation, the records it's affecting, and the SELECT query and which records it needs to read.
If a certain DML operation only causes a row level lock, then only those specific rows will be locked and SELECTs against those rows will be blocked while waiting for the DML lock to be released. SELECTs against other rows of the same Table will not be blocked. If the DML operation escalates to a Table level lock, then all SELECT queries against that table will be blocked throughout. Bear in mind, most times this is usually very quick either way, and not a concern (unless it's a poorly constructed DML operation).
The previous is true regardless if you have indexes or not, the only difference is some DML operations can be slightly slower, the more indexes that exist on a Table, such as INSERT operations. But conversely other DML operations like UPDATES generally perform better with the appropriate indexes on the Table, since the indexes help the UPDATE operation locate which records to update.
Since OP meant they are using the READ UNCOMMITTED isolation level, direct row and Table level locking does not apply then from writers blocking readers as normally would be in the default isolation level, READ COMMITTED.
BUT a heavy DML operation can still affect performance of a SELECT query by causing contention on the Table or Server. For example, if the table is compressed and a large amount of rows are UPDATEd by a single query, that can use a lot of CPU and I/O, and those server resources would be under contention throughout the operation causing other SELECT queries to potentially run slower on that server.
Sidenote, "huge data" is very subjective in the database world. I'm not sure what that means to you quantifiably, but I've worked in databases with Tables that had 10s of billions of rows, that did multiple DML operations to 1,000s of rows per minute and the SELECT performance was still excellent.